-Wformat warnings

[Kaveh R. Ghazi]

 > From: Martin Buchholz <martin@xemacs.org>
 >  
 > The -Wformat warnings are nice, but how does one turn them off when
 > the format string arg is non-constant?  In my opinion, the following
 > warning should never appear - it's a useless meta-warning.  There
 > doesn't seem to be an obvious way to suppress them.
 >  
 > /xemacs/ws/dev/src/lread.c:312: warning: format not a string
 > 	literal, argument types not checked
 >  
 > It would be nice if warnings could be properly done for this:
 >  
 >           fprintf (stderr,
 >                    (c >= 0x20 && c <= 0x7E) ? "UU%c" :
 >                    ((c == '\n') ? "UU\\n\n" : "UU\\%o"), c);
 >  


Yes many people have complained about this.  I think there are two
sides to this issue, sometimes this warning points out hidden bugs.

Imagine if in one of the ?: branches the format string was "UU%c%c".
You wouldn't know there was a problem because the compiler couldn't
detect it.  This new warning is telling you "don't be lulled into a
false sense of security about your fprintf statements.  Here is a case
where I couldn't guarantee the format matches the arguments."  So IMHO,
its not useless at all.

Anyway, no one has stepped up to the plate and provided a way to turn
it off independent of -Wformat.  But I expect there to be one before
the next official release.

Regarding handling the case you posted, its non-trivial to apply the
proper format warnings across ?: branches.  Essentially we'd have to
calculate the possible values and if *those* values are all literal,
then apply the format checks to these specifiers with the remaining
arguments.  Then people will say, why stop there?  Figure out
comma-list expressions.  Figure out statement expressions.  Figure out
nested expressions containing all the above mixed.  Figure out ...
You get the idea.

After all of that, note in your example above, your "UU\\n\n" branch
would still make noise because it doesn't account for the argument
`c'.  This is a case of a hidden (coincidentally harmless) format
problem in your own example.  You're not seeing it warn now precisely
because gcc isn't able to check this statement.  And now it tells you
so.

So I've found that its normally best to actually fix these cases.
Your example above could be rewritten as:

 >      if (c >= 0x20 && c <= 0x7E)
 >        fprintf (stderr, "UU%c", c);
 >      else if (c == '\n')
 >        fprintf (stderr, "UU\\n\n");
 >      else
 >        fprintf (stderr, "UU\\%o", c);

I know its a pain, but IMHO its worthwhile.  I'll bet in a program as
large as Xemacs, you'll uncover actual bugs.  I certainly did when
using this warning on gcc itself.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions