passing variable numbers of arguments

[Daniel F. Fisher]

In article <9381 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn ) writes:
>In article <202 at mstan.Morgan.COM> dff at Morgan.COM (Daniel F. Fisher) writes:
>>Since arrays cannot be passed by value in C, I fail to see how this
>>is relevant.
>
>                                   . . . sizeof returns the size of an
>object when used as a member of an array. . . .

I see Mr. Gwyn's point, and I believe it is relevant.

>>What to do? What to do?
>
>Not to worry about va_nargs().  It's not useful enough to be worth
>the hassle.

That is the opinion I expressed in my earlier posting.  I indicated
that while a va_nargs(parg, type) macro is portable way for functions
to count their arguments, I felt that this would be wasteful, given
that other means were available, such as rewriting a function that
uses va_nargs() so that it takes its argument count as an argument.

My "What to do? What to do?" followed a discussion of how to implement
va_arg() in such away that when NDEBUG was not defined it would cause
the program to abort() if there were no remaining arguments of the
requested type.  What I couldn't figure out was how to implement this
facility so it did not beget the same overhead as that which is
inherent in va_nargs().  Specifically, I was wondering how to construct
a calling sequence that was ambivalent to the presence of argument count
information but which would allow the callee to ascertain the presence
of this information.

Perhaps a va_arg() macro that aborts if it does not have an argument
is also not worth the hassle.  Particularly if it requires the same
additional overhead in all function calls as va_nargs() appears to
require.  But I do believe it is MORE of a hassle than va_nargs().


In article <11428 at haddock.ima.isc.com> karl at haddock.ima.isc.com (Karl Heuer)
writes on the same subject:

>Actually, both va_nbytes() and va_nargs() are more powerful than necessary.
>Typically, all the user wants to know is whether or not there is another
>argument available for fetching with va_arg(), so a boolean va_isarg() would
>suffice.

I considered suggesting va_isarg() when preparing my earlier posting,
but concluded that it is not appropriate, since the unavailability
of a necessary argument represents a programming error which is best
treated as an assertion failure.  This is what led me to suggest that
va_arg abort if it cannot return an argument of the requested type.
I can see, however, that a more general form of assert() might invoke
an exception handler, so I wish to modify my earlier descriptions of the
"bullet-proof" va_arg() to be "like the usual va_arg() except that,
prior to returning the argument, it asserts that it can and allows
assert() to take the usual action if the assertion fails."

-- 
Daniel F. Fisher
dff at morgan.com