__builtin_va_list bug or feature

[Joseph S. Myers]

On Fri, 25 Apr 2003, Gisle Vanem wrote:

> Black talk and geek speech. The code is always executed when the format 
> in question was used (%D in a custom va-function). 

The format needn't be used in a given execution of the program.  DR#109
<http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_109.html> is quite
explicit about what conforming implementations must do in such
circumstances:

   A conforming implementation must not fail to translate a strictly
   conforming program simply because _some_ possible execution of that
   program would result in undefined behavior.

> So the unpromote type is wrong, so what! The djgpp va_arg() macro 
> picks up the wrong type, but the stack isn't messed up. I'd rather prefer 
> wrong output than a generated trap. Which neither MingW nor djgpp
> have handlers for. Seems gcc is biased towards Linux in this case.

The ABI won't in general specify the interface for unpromoted types
because the C promotion rules mean they cannot arise as arguments to be
accessed by va_arg; complicated macros are liable to yield some quieter
form of undefined behavior at runtime (e.g. silent data corruption), but
with a built-in operator it is possible to do better; a generated trap
means the problem gets detected at runtime (hopefully in the course of
running a testsuite for the code if not before then), if somehow it wasn't
fixed after the warning was given.  This is much better than silent data
corruption, a likely other form of undefined behavior.  The natural
alternative to generating a trap would be for the compiler to reason that
undefined behavior means that the code in question cannot be reached and
optimize the rest of the program on that basis, which would be riskier
(and in this case unlikely to be a useful optimization).

-- 
Joseph S. Myers
jsm28@cam.ac.uk