variable number of arguments

[Dan Heller]

In article <7361 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <51 at vsi.UUCP> friedl at vsi.UUCP (Stephen J. Friedl) writes:
>>     I have no specific reason to doubt the portability, but it
>>strikes me that since args are so crazy on various machines (stack
>>grows up, stack grows down, params passed in registers, etc.)
>>that letting varargs handle *all* the details would not be a bad
>>idea.
>
>In fact that's the right way to use varargs.  Declaring part of
>the argument list is the wrong way.  (This is the opposite of
>ANSI C <stdarg.h> macros, where there MUST be at least one
>"anchor" argument declared right before the variadic part.)

I have reservations about wanting to use varargs for _all_ the arguments
passed to the function.  While lint be be told not to "complain", it avoids
lint's ability to find potential mistakes in the calling routines.  The
example that the original poster used was a good one (altho I don't remember
it exactly, it went something like):

    function(X, Y, fmt, args)
    int X, Y;
    char *fmt;
    va_dcl

Next, to help the lint (and the reader of someone else's code), we can
add:

    /*VARARGS3*/
    function(X, Y, fmt, args)

Stephan has an interesting point:
>>strikes me that since args are so crazy on various machines (stack
>>grows up, stack grows down, params passed in registers, etc.)
>>that letting varargs handle *all* the details would not be a bad
>>idea.

I refute that claiming that it shouldn't be necessary to worry about
it.  A good compiler will pass the arguments correctly and the architecture
should be completely transparent to the programmer.  Declaring the _known_
arguments makes the code more easily linted and more easily understood by
others readers.
			...dan