On 11/29/2011 02:27 PM, Paul Eggert wrote: > On 11/29/11 13:18, Jim Meyering wrote: >> Have you found code that triggers a -Wformat-zero-length warning >> yet that doesn't seem worth adjusting? > > I haven't run into it one way or another, but all my instincts are > against that diagnostic. I suspect that the most-common way that it > would happen would be something like this admittedly-contrived example: > > #if FEATURE_ENABLED > #define FEATURE_FORMAT "feature" > #else > #define FEATURE_FORMAT "" > #endif > ... > printf (buf, FEATURE_FORMAT);
I assume you meant sprintf (buf, FEATURE_FORMAT), or printf
(FEATURE_FORMAT)?
>
> where the printf can be optimized away if FEATURE_ENABLED
> is zero, and the compiler is warning us about that.
Ah, but then I would use these more efficient idioms, which also avoids
the compiler warning:
puts (FEATURE_FORMAT) (replacing the printf case)
strcpy (buf, FEATURE_FORMAT) (replacing the sprintf case)
> This reminds me too much about bogus warnings that some compilers
> give for this:
>
> enum { N = FEATURE_ENABLED ? 1000 : 0 };
> ...
> for (i = 0; i < N; i++)
> foo (i);
>
> where the compiler proudly warns that it has optimized the loop
> away entirely, and did I really mean that? (Yes I did! and I don't
> want to be warned about it! :-)
I agree that a noisy compiler telling you about dead code due to
optimizations is a pain, but until we actually encounter the noise, I
can't say whether the signal-to-noise ratio warrants removing the
warning by default.
--
Eric Blake ebl...@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
