stdarg definitions

**Hallvard B Furuseth** · Mar 20 '07, 04:15 PM

Re: stdarg definitions

"cman" <tilakb@gmail.c omwrites:

Can somebody explain the following code segment, from stdargs.h (from
linux 0.01)
>
#define __va_rounded_si ze(TYPE) \
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof
(int))va_rounde d_size

(X + K-1)/K*K rounds X up to a whole multiple of K - so if
sizeof(TYPE) == 6 and sizeof(int) == 4, this becomes 8.
The final "va_rounded_siz e" looks like a typo.

The following code appears to assume that the arguments are put after
each other in a contiguous memory area, at addresses (address of first
argument + some multiple of sizeof(int)). So...

#define va_start(AP, LASTARG) \
(__builtin_save regs (), \
AP = ((char *) &(LASTARG) + __va_rounded_si ze (LASTARG)))

Presumably __builtin_saver egs() does some magic to prepare for use of
stdarg. The AP is set to point to the argument following LASTARG.

#define va_arg(AP, TYPE) \
(AP += __va_rounded_si ze (TYPE), \
*((TYPE *) (AP - __va_rounded_si ze (TYPE))))

AP points at the next argument to be fetched. That argument is returned
after stepping AP up to to point to the next argument.

--
Regards,
Hallvard

**Dave Vandervies** · Mar 20 '07, 04:25 PM

Re: stdarg definitions

In article <1174406522.478 803.285330@n76g 2000hsh.googleg roups.com>,
cman <tilakb@gmail.c omwrote:

>Can somebody explain the following code segment, from stdargs.h (from
>linux 0.01)
>
>#define __va_rounded_si ze(TYPE) \
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof
>(int))va_round ed_size
>
>#define va_start(AP, LASTARG) \
(__builtin_save regs (), \
AP = ((char *) &(LASTARG) + __va_rounded_si ze (LASTARG)))
>
>#define va_arg(AP, TYPE) \
(AP += __va_rounded_si ze (TYPE), \
*((TYPE *) (AP - __va_rounded_si ze (TYPE))))
>
>What are the above macros trying to accomplish?

They're implementing the compiler magic that va_start and va_arg need
to know where to find the arguments you ask them for.
(In general, you shouldn't care how they accomplish this; to write code
using them, you only need to know what they do, not how they do it.
Using knowledge of how they work underneath is more likely to get you
into trouble than to help you.)

In this case, it looks like arguments (at least the last non-variable
argument and the variable arguments to a variadic function) are
stored as if they were memcpy'd into an array of bytes with alignment
of sizeof(int). (This alignment makes sense, since every type smaller
than int (unless pointers are smaller than int, which I don't believe
they are on most implementations ) is promoted to int when it gets passed
as a variable argument.)
So va_start takes the location of the last non-variable argument and
uses it to calculate the location of the first variable argument, and
va_arg takes the location of the next variable argument (stored in the
va_list), updates the va_list to reflect the fact that an argument has
been consumed, and returns the next variable argument (by treating the
collection of bytes in the right place as an object of the reqested type).

dave

--
Dave Vandervies dj3vande@csclub .uwaterloo.ca
If parachutes were maintained to the same standards as the typical car
you'd have parachutists dropping out of the skies like flies.
--Bram in the scary devil monastery

**Chris Torek** · Mar 25 '07, 07:35 AM

Re: stdarg definitions

>In article <1174406522.478 803.285330@n76g 2000hsh.googleg roups.com>

>cman <tilakb@gmail.c omwrote:

>>Can somebody explain the following code segment, from stdargs.h ...

[snip lots of machine-dependent stuff]

In article <etp1hm$sh5$1@r umours.uwaterlo o.ca>,
Dave Vandervies <dj3vande@caffe ine.csclub.uwat erloo.cawrote:

>They're implementing the compiler magic that va_start and va_arg need
>to know where to find the arguments you ask them for.
>(In general, you shouldn't care how they accomplish this; to write code
>using them, you only need to know what they do, not how they do it.
>Using knowledge of how they work underneath is more likely to get you
>into trouble than to help you.)

Right.

>In this case, it looks like arguments (at least the last non-variable
>argument and the variable arguments to a variadic function) are
>stored as if they were memcpy'd into an array of bytes with alignment
>of sizeof(int). (This alignment makes sense, since every type smaller
>than int (unless pointers are smaller than int, which I don't believe
>they are on most implementations ) is promoted to int when it gets passed
>as a variable argument.)

Yes, but there is a bug, on this particular implementation
(fixed in later versions of the <stdarg.hmacr os and compiler).

>So va_start takes the location of the last non-variable argument and
>uses it to calculate the location of the first variable argument, and
>va_arg takes the location of the next variable argument (stored in the
>va_list), updates the va_list to reflect the fact that an argument has
>been consumed, and returns the next variable argument (by treating the
>collection of bytes in the right place as an object of the reqested type).

All of this works fine for char, short, and int arguments and
for double and long double arguments. The bug occurs when the
"last fixed argument" has type "float":

#include <stdarg.h>

void foo(int nargs, float firstfloat, ...) {
va_list ap;

va_start(ap, foo);
vfoo(nargs, firstfloat, ap);
va_end(ap);
}

void vfoo(int nargs, float firstfloat, va_list ap) {
float cur;

for (cur = firstfloat;;) {
operate(cur); /* replace this with real code */

if (--nargs <= 0)
break;

/*
* Note that we cannot use va_arg(ap, float) here,
* since floats that correspond to the ", ..." part
* were promoted to "double" by the caller.
*
* Some versions of <stdarg.hattemp t to catch
* the use of "float" as the "type" and automatically
* convert it to "double", but technically we, as
* C programmers, are supposed to just use "double".
*/
cur = va_arg(ap, double);
}
}

The above is (assuming I have not done something silly) good,
solid, conforming Standard C code. We might call it with, e.g.:

extern void foo(int, float, ...);

foo(3, 1.5, 15.0, 150.0);

The implementation that tilakb@gmail.co m asked about, however, will
break, because the C compiler handles the va_start() in foo()
incorrectly: it takes "sizeof(flo at)" as the number of bytes to
"skip over" in order to find the first only-as-precise-as-float-
but-promoted-to-double argument -- i.e., 15.0 -- but that particular
implementation (which I am sure about; I see it in my crystal
ball :-) ) actually *also* promotes the fixed argument ("firstfloat ")
to double. The implementation-specific macros (__va_rounded_s ize
and so forth) fail to take this into account.

Newer versions of the compiler, with their newer <stdarg.h>, tend
to dump more of the problem on the compiler. Instead of just one
__builtin, they use a whole series.

The "correct" (or ideal, anyway) solution is of course to dump the
*entire* problem on the compiler: have a __builtin_va_li st type
(which the compiler allocates and knows about), have a __builtin_va_st art
(the compiler knows how to save and/or locate the variable arguments),
and have a __builtin_va_ar g (the compiler knows how to take a type
name and use that to extract a variable argument). Of course, if
one does this, one arrives at:

typedef __builtin_va_li st va_list;
#define va_start(ap, X) __builtin_va_st art(ap)
#define va_arg(ap, type) __builtin_va_ar g(ap, type)
#define va_end(ap) __builtin_va_en d(ap)

Note that this sequence of four source-code lines is itself completely
machine-independent (even though each __builtin_* is completely
machine-dependent): EVERY C compiler on EVERY system could have
used EXACTLY those four lines, provided that every C compiler were
to provide those four __builtin_* names. Note further that the
second argument to __va_start is unused, and therefore need not
ever have been required. The original C89 standard should have
used the original pre-C89 <varargs.hsynta x (which omitted the
second argument to va_start()). The whole problem I describe above
(with promoted float arguments) would never have arisen.

Providing <stdarg.has a header is still a good idea. On
compilers where no "setup" or "teardown" is required to make
the arguments accessible, a C compiler could have used this:

typedef __builtin_va_li st va_list; /* or typedef char *, etc */
#define va_start(ap) ((ap) = &...)
#define va_end(ap) /*nothing*/
#define va_arg(ap, type) __builtin_va_ar g(ap, type)

In other words, such a C compiler (e.g., gcc 1.x for x86) could
simply have made the "..." pseudo-variable addressable. On
more complicated systems (SPARC, PowerPC) that pass arguments
in registers, va_start would still need to use some __builtin,
but could still be defined fairly simply:

typedef __builtin_va_li st va_list; /* compiler provides size of save area */
#define va_start(ap) (__builtin_va_s tart(ap))
#define va_end(ap) /*nothing*/
#define va_arg(ap, type) __builtin_va_ar g(ap, type)

But instead we have these old, muddle-headed, slightly broken
implementations that attempted to use a slightly broken idea embedded
in the Standard, instead of ignoring the broken idea to start with
and thus avoiding the problem. :-)

(For anyone who actually read this far: if you want to avoid
encountering the bug, make sure your "last fixed argument" to any
variable-argument function never has a type that undergoes promotion.
It is *supposed* to work, but at least some cases -- floats -- fail
on at least some implementations . Other implementations may even
get char and short wrong as well.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

stdarg definitions

stdarg definitions

Comment

Comment

Comment