Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!purdue!decwrl!decvax!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: passing variable numbers of arguments
Message-ID: <11428@haddock.ima.isc.com>
Date: 14 Jan 89 08:12:23 GMT
References: <899@thor.stolaf.edu> <15341@mimsy.UUCP> <449@marob.MASA.COM> <9317@smoke.BRL.MIL> <11378@haddock.ima.isc.com> <9321@smoke.BRL.MIL> <11410@haddock.ima.isc.com> <9358@smoke.BRL.MIL>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Distribution: na
Organization: Interactive Systems, Boston
Lines: 26

In article <9358@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <11410@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>>... given this information, the code ... is portable.
>
>No it isn't!!  ... your use of sizeof to adjust the byte count is flawed,
>because sizeof doesn't take into account alignment requirements of the
>arguments, which can (and sometimes do) differ from those of array members.

I'm assuming that va_nbytes() would be *defined* to return sum(each undeclared
argument a)(sizeof(a)), rather than the amount of space used on the stack.  On
implementations where these agree, there may be a fast way to compute the
value from the callee.  On implementations with the strange alignment
requirements, or where other problems prevent the callee from doing this, the
compiler would have to provide the information at the caller's end.

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.  Any implementation on which it is currently possible to write either
va_nbytes() or va_nargs() correctly could add va_isarg() in such a way that
there is no cost associated with it in programs that don't use it.  (There are
implementations in which none of these three can be written without passing
hints from the caller, which is probably the main reason why this isn't worth
standardizing.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint