By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,750 Members | 1,199 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,750 IT Pros & Developers. It's quick & easy.

stdarg definitions

P: n/a
Can somebody explain the following code segment, from stdargs.h (from
linux 0.01)

#define __va_rounded_size(TYPE) \
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof
(int))va_rounded_size

#define va_start(AP, LASTARG) \
(__builtin_saveregs (), \
AP = ((char *) &(LASTARG) + __va_rounded_size (LASTARG)))

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

What are the above macros trying to accomplish?

Tilak

Mar 20 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"cman" <ti****@gmail.comwrites:
Can somebody explain the following code segment, from stdargs.h (from
linux 0.01)

#define __va_rounded_size(TYPE) \
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof
(int))va_rounded_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_size" 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_saveregs (), \
AP = ((char *) &(LASTARG) + __va_rounded_size (LASTARG)))
Presumably __builtin_saveregs() 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_size (TYPE), \
*((TYPE *) (AP - __va_rounded_size (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
Mar 20 '07 #2

P: n/a
In article <11**********************@n76g2000hsh.googlegroups .com>,
cman <ti****@gmail.comwrote:
>Can somebody explain the following code segment, from stdargs.h (from
linux 0.01)

#define __va_rounded_size(TYPE) \
(((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof
(int))va_rounded_size

#define va_start(AP, LASTARG) \
(__builtin_saveregs (), \
AP = ((char *) &(LASTARG) + __va_rounded_size (LASTARG)))

#define va_arg(AP, TYPE) \
(AP += __va_rounded_size (TYPE), \
*((TYPE *) (AP - __va_rounded_size (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 dj******@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
Mar 20 '07 #3

P: n/a
>In article <11**********************@n76g2000hsh.googlegroups .com>
>cman <ti****@gmail.comwrote:
>>Can somebody explain the following code segment, from stdargs.h ...
[snip lots of machine-dependent stuff]

In article <et**********@rumours.uwaterloo.ca>,
Dave Vandervies <dj******@caffeine.csclub.uwaterloo.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.hmacros 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.hattempt 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 ti****@gmail.com asked about, however, will
break, because the C compiler handles the va_start() in foo()
incorrectly: it takes "sizeof(float)" 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_size
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_list type
(which the compiler allocates and knows about), have a __builtin_va_start
(the compiler knows how to save and/or locate the variable arguments),
and have a __builtin_va_arg (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_list va_list;
#define va_start(ap, X) __builtin_va_start(ap)
#define va_arg(ap, type) __builtin_va_arg(ap, type)
#define va_end(ap) __builtin_va_end(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.hsyntax (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_list va_list; /* or typedef char *, etc */
#define va_start(ap) ((ap) = &...)
#define va_end(ap) /*nothing*/
#define va_arg(ap, type) __builtin_va_arg(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_list va_list; /* compiler provides size of save area */
#define va_start(ap) (__builtin_va_start(ap))
#define va_end(ap) /*nothing*/
#define va_arg(ap, type) __builtin_va_arg(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 (4039.22'N, 11150.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.
Mar 25 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.