Re: va_arg regression from 2.95.2 to 3.1

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 14:28 27.03.2002, Joseph S. Myers wrote:
>On Wed, 27 Mar 2002, Richard Henderson wrote:
>
> > On Wed, Mar 27, 2002 at 09:25:44AM +0100, Schirmer, Hartmut wrote:
> > > Since
> > >         res = va_arg(ap,int16);
> > > will never be executed the compiler shouldn't give an error.
> >
> > Possibly.  I'm unconvinced.
>
>I think the argument is correct, and that this call to va_arg should be
>considered the same as a call where the types turn out to be incompatible
>at runtime (except here, the runtime type cannot be compatible).  It ought
>to be a mandatory warning (not pedwarn, not error); and should either be
>compiled into a call to abort() or be treated as a call to va_arg with the
>promoted type followed by conversion to the type specified.

I disagree, cause in this case if the types are incompatible at runtime you 
have a bug in your program for 100%. The example is rather artificial, 
cause I see no reason to write such code. If he intends to pass a 16-bit 
int on 32bit int and 16bit int platforms, he can write the usual "(int16_t) 
va_arg(ap,int)".

IMO the callee "knows" (eg. deduced from the format string like printf) the 
intended final types anyway and thus any mismatch is a coding bug.

 From a practical point of view the number of varargs related bug reports 
on powerpc-linux dropped to zero since gcc-2.96/gcc-3.0 are in widespread 
use, forcing x86 centric package maintainers to fixup their code.

So I want the unconditional error to stay.

Franz.