bug#12164: What is the right way to specify -Wno-format-contains-nul?

[Stefano Lattarini]

severity 12164 wishlist
tags 12164 wontfix
thanks

On 08/09/2012 09:58 PM, Bruce Korb wrote:
> Hi,
>
> It seems that AM_PROG_CC
>
Huh?  There is no such think like 'AM_PROG_CC'.  I guess you mean
AC_PROG_CC.

> likes to default CFLAGS to "-g -Wall"
>
Since AC_PROG_CC comes from Autoconf, this is not due to Automake in
any way.  Maybe you should ask on their list how to prevent this from
happening.

> and COMPILE puts CFLAGS at the end of the option list.
>
Rightly so, because user overrides are expected to always take
precedence.

> That means that -Wall over-rides my AM_CFLAGS setting and chokes
> and dies.
>
How can -Wall cause the compiler to die?  Have you added -Werror to
$(AM_CFLAGS) maybe?

> My library uses a large array of bytes to hold many strings,
> some of which are formatting strings and gcc is really clever about
> noticing that there are embedded NUL bytes separating each substring.
> (I actually added -Wno-format-contains-nul shortly after this new
> cleverness was added...)  The deal is that if someone does a:
> 
>    make CFLAGS='-Dsomethingforme -Wall'
> 
> and I were to add this nul thingey to the end of CFLAGS, then
> my effort is for naught.  I think it useful to have a PROJECT_CFLAGS
> that always gets stuck at the end in the COMPILE macro.
>
This would go against the principle that "the user is always right (when
he is explicit)".  If your users want to instruct your package to do
something stupid, allow them; it might turn out that what might seem
stupid is actually subtly clever or useful in some corner-case situations.
So, in this case above, the user will just learn to add a '-Wno-error'
option to his CFLAGS if he wants to avoid spurious errors; maybe he
is using '-Wall' not to cause extra errors, but because he wants to
see which the warnings you have disabled are, for his own reasons (good
or bad, that is not for us to speculate about).  Your proposed idiom
would prevent him from doing so easily.

We can't start trying to double-guess or out-smart the user: there lies
madness (and some Windows programs ;-)  Because, in the end, what would
prevent the user from overriding $(PROJECT_CFLAGS) as well?

> Meanwhile, I'll specify it twice -- once in CFLAGS and again in AM_CFLAGS
> in hopes it remains active regardless.
>
This way, you are preventing your user a way to define $(CFLAGS) himself;
not a good move.

> (Actually, gcc probably ought not override a specifically set option
> with a "-Wall", but this the wrong forum for that...)
> 
> Thanks - Bruce
> 

Regards,
  Stefano