Re: "format not a string literal"

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Ulrich" == Ulrich Drepper <drepper@cygnus.com> writes:

    Ulrich> Simply leave the compiler out of this kind of business.
    Ulrich> Even if you cannot think about any useful use, others
    Ulrich> might.  You should be humble in this respect and not in an
    Ulrich> arrogant way demand that everybody follows your
    Ulrich> "guidelines" of writing good C code.

I would have worded this more gently, but, for the most part, I agree.
I think warnings about truly suspicious constructs (`if (x = 3)') are
worthwhile, even if occasionally the programmer meant to do this kind
of thing.  But, the new -Wformat changes strike me as something more
like a coding standards thing than a compiler thing.

One of the reasons I'd like to continue to make the front-ends
separable units is so that people *can* build these kinds of
coding-standards tools.  But, the compiler *itself* should not become
one.  For now, we've little choice; there is no way to do the coding
standards checks outside of GCC because there was no way to get just
the front-end; if we can fix this, life will be better.

I worked for quite some time designing and building error-checkers.
The signal-to-noise ratio has to be *very* high, or most people simply
do not take advantage of the tool.  For example, if one of every
twenty "maybe unitialized before use" warnings is correct, very few
people will actually track them down and find the problem.

So, I agree: writing `char *s; printf (s);' is dangerous; it prevents
type-checking by the compiler.  It's quite reasonable to say that "on
our project, we won't do this".  But, I don't think this should be
part of -Wall; that should contain picky, but most often useful,
warnings about portability problems and practices that are almost
always dangerous.  I'm not even sure the new -Wformat check should be
in the compiler at all; a separate tool (or loadable module) seems
like the place for this to me.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com