va_arg regression from 2.95.2 to 3.1
Franz Sirl
Franz.Sirl-kernel@lauterbach.com
Wed Mar 27 09:24:00 GMT 2002
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.
More information about the Gcc-bugs
mailing list