This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: va_arg regression from 2.95.2 to 3.1
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Cc: Richard Henderson <rth at redhat dot com>, "Schirmer, Hartmut" <HSchirmer at Innovative-Systems dot de>, "'gcc-bugs at gcc dot gnu dot org'" <gcc-bugs at gcc dot gnu dot org>
- Date: Wed, 27 Mar 2002 14:30:26 +0000 (GMT)
- Subject: Re: va_arg regression from 2.95.2 to 3.1
On Wed, 27 Mar 2002, Franz Sirl wrote:
> 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.
It is quite deliberate that the format warnings with -pedantic are
warnings, not pedwarns, since the code may not be executed (they were
changed from pedwarns to warnings in revision 1.10 of c-common.c, in the
early days of EGCS). This case is the same; the code may not be executed,
and a program in which it is never executed can be strictly conforming.
> 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.
Compiling to abort() (rather than DWIM compiling as if the promoted type
had been specified) preserves most of this benefit, since bugs will show
up on all systems.
--
Joseph S. Myers
jsm28@cam.ac.uk