compiler warnings

[Brian J. Tarricone]

On Fri, 26 Dec 2008 14:30:11 +0100 Nick Schermer wrote:

> 2008/12/25 Brian J. Tarricone <bjt23 at cornell.edu>:
> > To preface, gcc 4.3.2 here.
> >
> > On Thu, 25 Dec 2008 14:06:23 +0100 Nick Schermer wrote:
> >
> >> -Wformat-nonliteral:
> >> Makes g_strdup_printf (format, message); unusable (both variables).
> >> Same for strftime related functions.
> >
> > Well, if "format" is a variable from an untrusted source (and not a
> > string literal), I *do* want a warning thrown, as that could be a
> > security vulnerability.  If "format" is a variable with format
> > specifiers constructed by the programmer, then yeah, that's
> > annoying, but perhaps there's a better way to write that code
> > that's less ambiguous.
> >
> > I guess possibly I could leave off -Wformat-nonliteral and replace
> > it with -Wformat-security.  It's not quite as safe -- you could
> > still concat a fixed format string with something supplied by the
> > user, and then supply a single extra argument to printf(), and it
> > would be unsafe, but get by without a warning, but this is better
> > than nothing.
> 
> -Wformat-security is already in the list and is triggered for all the
> printf functions (ie the const gchar *format, ...).
> -Wformat-nonliteral only 'breaks' strftime here, because i convert
> the utf-8 to the current locale. And although the format is defined
> by the user I don't really see a security problem here. (and with
> -Werror the compilation aborts).

Yeah, I see what you're saying.  Let's just leave off
-Wformat-nonliteral and keep -Wformat-security.

I also noticed another annoyance.  Something that -Wextra enables (I
assume -Wignored-qualifiers) causes warnings for code like this:

/* e.g. in some system header */
struct Foo {
    char *bar;
    int baz;
}

/* in our code */
struct Foo quux = { "your mom", 4 };

The above line triggers a "initialization discards qualifiers from
pointer target type" warning because "your mom" is of type (const char
*), and the struct expects (char *).  Really, the fault is in the
struct, but we can't change things like GtkTargetEntry.

This also gets triggered when a string literal is passed to a function
that takes a (char *) and not a (const char *), which is annoying for
args 3 and 5 of gtk_init_with_args(), among others.

I'm guessing this warning got beefed up in gcc4 and moved from -Wall to
-Wextra for exactly this reason.  IIRC it used to only warn in cases
where you assign a const variable or const function return to a
non-const variable, which, yeah, that's a place where you probably want
a warning.  But with the new(?) semantics of also warning for passing
string literals where non-const is expected, that can be pretty
annoying (though understandable, since it's technically a correct place
to warn, even if there are many many examples in practice where this
isn't a big deal).

So, I'm tempted to also add -Wno-ignored-qualifiers, but at the same
time that will hurt the case of things like:

/* in some header */
const char *give_me_a_foo();

/* in our code */
char *foo = give_me_a_foo();
/* oh crap, this is bad, but the compiler won't warn */
foo[2] = ' ';

With -Wignored-qualifiers, the above code will throw a warning on the
first assignment.  Then you fix it by adding 'const', and then you get
an error on the second assignment and realise, oh, crap, I'm not
supposed to be modifying that variable.  So it's a useful warning, but
it just appears that (with gcc 4.3 at least), it's way too "chatty".

	-b