The second form is the correct one, as it has always been, regardless of
what gcc may or may not accept on some machines.
The Gospel, as interpreted by "ISO/IEC JTC1/SC22/WG14 - C" in the C9X Final
Committe Draft, says this about va_arg on page 235, section 7.15.1.1:
Synopsis
#include <stdarg.h>
type va_arg(va_list ap, type);
Description
..
The parameter \emph{type} shall be a type name specified such that
the type of a pointer to an object that has the specified type can
be obtained simply by postfixing a \texttt{*} to \emph{type}.
If there is no actual next argument, or if \emph{type} is not
compatible with the type of the actual next argument (as promoted
according to the default argument promotions), the behavior is
undefined, ...
As if this wasn't clear enough, the C9X Rationale states explicitly
(page 112, section 7.15.1.1) that:
..
it is important to remember that the type of an argument in a
variable argument list will never be an integer type smaller than
\texttt{int}, not will it ever be \texttt{float}.
It is not difficult to imagine at least two ways in which the first, buggy,
form "va_arg(args, short)" can misbehave: using a "short*" pointer to access
an "int", and incrementing the variable argument list "pointer" as if the
argument was "short" instead of "int".
Maybe gcc's <stdarg.h> contains a DWIM (*) which works on some machines, but
I wouldn't count on it. Just use the correct C code and don't worry, OK?
/Mikael
(*) DWIM = Do What I Mean, the name given to an automatic error correction
assistant in the Interlisp programming environment. I never liked it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/