passing variable numbers of arguments

[Doug Gwyn]

In article <449 at marob.MASA.COM> samperi at marob.masa.com (Dominick Samperi) writes:
>It seems that for the ANSI style varargs (that is, the one requiring
>stdarg.h), at least one explicitly named arg must be included in the
>function definition, so that there is a FIRST that can be supplied to
>va_start, ... Is this correct?

Yes.  Some implementors claimed that this "hook" was necessary in order
for their <stdarg.h> implementation to have a reference point for va_arg
to use.  I think actually with certain compiler trickery this could have
been made invisible to the programmer, but the Committee was willing to
require the "anchor" argument(s) to be present.  I've been programming
variable-argument functions with code for both __STDC__ and old UNIX C
for quite some time now, and this constraint hasn't been much of a
problem.

>It also seems to be the case that it is not possible for a called function
>(with a variable number of args) to determine how many args were actually
>passed, or when the last arg has been fetched, unless this information is
>supplied in the first parameter, say.

Yup.  This reflects existing C practice.  PDP-11 UNIX had an nargs()
function that purported to return the argument count, but it didn't
work right (it returned the number of words of arguments, not the count).
Making this work right would have slowed down every function call.
nargs() was practically unused...

>Wouldn't it have been reasonable for the standard to specify that the
>compiler should enable the called function to determine the number of
>parameters that were passed, by automatically passing this information
>as a first implicit parameter, for example?

Why burden all implementations all the time when you can provide this
yourself as a patent argument in those cases where you need it?

You could also use a "sentinel" argument, e.g.
	concat(dest,"str_a","str_b","str_c",(char*)0);