>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 (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.
