variable number of arguments
Bob Larson
blarson at skat.usc.edu
Sun Feb 28 18:36:02 AEST 1988
In article <1078 at pasteur.Berkeley.Edu> dheller at cory.Berkeley.EDU.UUCP (Dan Heller) writes:
>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:
>>>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 versions of lint I have used document, but do not support /*VARARGS0*/
(Sun 4.0 beta reportadly fixes this bug.) Lint will complain about correct
use of varargs because of this bug.
Writing non-portable code to shut lint up is something I consider very
poor practice.
>I refute that claiming that it shouldn't be necessary to worry about
>it.
Claiming something doesn't make it so. I claim that compiler writers
shouldn't have to worry about non-portable code. (Note that my claim
seems to be supported by the ANSI C commitee.)
Guy Harris and I had a long email discussion relating to this, and
there were only two cases where he was able to convince me
/*VARARGSn*/ where n!=0 should be allowed: where portability checking
was explictily turned off, and lint libraries.
--
Bob Larson Arpa: Blarson at Ecla.Usc.Edu blarson at skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list: info-prime-request%fns1 at ecla.usc.edu
oberon!fns1!info-prime-request
More information about the Comp.lang.c
mailing list