mcdonald@uxe.cso.uiuc.edu (10/26/88)
>And so on. Use <varargs.h> or <stdarg.h> >(current practice and ANSI-C-draft practise respectively); they are the >*only* portable way to do this. Oh come on now. How about mallocing up enough space to put an array of pointers to the strings in memory and passing a pointer to that array? That is portable and avoids varargs or stdarg.
crossgl@ingr.UUCP (Gordon Cross) (11/01/88)
In article <225800083@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > Oh come on now. How about mallocing up enough space to put an array > of pointers to the strings in memory and passing a pointer to that array? > That is portable and avoids varargs or stdarg. Yes this is true: portability is maintained and you avoid the (messy??) varargs convention. However, I would NOT recommend using malloc in this fashion for two reasons: 1) First, mallocing memory is usually a costly (timewise) undertaking when compared to the time it takes to pass arguments. Most decent compilers should pass arguments using the most efficient method possible. If you are calling such a function many times, you may find yourself spending all of your time mallocing and freeing! 2) Your code would be "messy" (descriptive term) in the areas where you call this function because you would have to do this: buffer = (char **)malloc (size); buffer[0] = "arg1"; buffer[1] = "arg2"; . . . buffer[n] = 0; yourfunction (buffer); free (buffer); If you have to do this in very many different places, your code size could adversely affected. Wouldn't it be much nicer to be able to call the function with the single line yourfunction ("arg1", "arg2", ... , 0); Gordon Cross Intergraph Corp. Huntsville, AL
mcdaniel@uicsrd.csrd.uiuc.edu (11/04/88)
Written 11:08 am Oct 31, 1988 by crossgl@ingr.UUCP in comp.lang.c: > Wouldn't it be much nicer to be able to call the function with the > single line > yourfunction ("arg1", "arg2", ... , 0); > Gordon Cross > Intergraph Corp. Huntsville, AL Yes, it would be nice if you could do that. However, the line as given above is erroneous (although likely to work in many implementations). Either yourfunction ("arg1", "arg2", ... , (char *) 0); or yourfunction ("arg1", "arg2", ... , (char *) NULL); works. If you don't believe me, I'll e-mail you a copy of Chris Torek's articles "Why NULL is 0" and "Re: NULL etc.", the definitive works on the subject. -- Tim, the Bizarre and Oddly-Dressed Enchanter Center for Supercomputing Research and Development at the University of Illinoid at Urbana-Champaign Internet, BITNET: mcdaniel@uicsrd.csrd.uiuc.edu UUCP: {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel ARPANET: mcdaniel%uicsrd@uxc.cso.uiuc.edu CSNET: mcdaniel%uicsrd@uiuc.csnet DECnet?: GARCON::"mcdaniel@uicsrd.csrd.uiuc.edu"
kirkaas@oahu.cs.ucla.edu (paul kirkaas) (11/12/88)
One more observation on the Portablility / variable number of arguments discussion: I had a whole set of vararg.h routines running happily on my AT&T Unix 3B1. I ported them to a Pyramid where they crashed and burned on compilation. So even using varargs is no guarantee of portability with variable arguments.
chris@mimsy.UUCP (Chris Torek) (11/12/88)
In article <17850@shemp.CS.UCLA.EDU> kirkaas@oahu.cs.ucla.edu (paul kirkaas) writes: >I had a whole set of vararg.h routines running happily on my AT&T Unix 3B1. >I ported them to a Pyramid where they crashed and burned on compilation. >So even using varargs is no guarantee of portability with variable >arguments. Varargs works fine on Pyramids. You must, of course, constrain yourself to use them in accordance with the manual, including avoiding things like for (va_start(ap); <cond>; <iter>) stmt; va_end(ap); which `look fine' on a casual scan but are not in fact legal. In fact, va_start compiles to one statement on the 3B, but includes a left brace and a declaration on the Pyramid. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/12/88)
In article <17850@shemp.CS.UCLA.EDU> kirkaas@cs.ucla.edu (paul kirkaas) writes: >I had a whole set of vararg.h routines running happily on my AT&T Unix 3B1. >I ported them to a Pyramid where they crashed and burned on compilation. >So even using varargs is no guarantee of portability with variable >arguments. Perhaps you weren't using varargs properly. I've used varargs on Pyramids with no problems. (In fact it was essential!)