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