Re: "format not a string literal"

[Ken Raeburn <raeburn at raeburn dot org>]

Ulrich Drepper <drepper@cygnus.com> writes:
> But the __builtin_constant_p in dcgettext will not work.  That's the
> whole purpose.  Read the comments in libintl.h.

One libintl.glibc I found on my system (from the binutils sourceware
repository) just says, basically, "__builtin_constant_p won't work in
an inline function".  None of the other copies of libintl.h I found
say anything about it.

This behavior seems to have changed.  With the egcs-1.1.2 release
(which I was using for some of the testing, at home), this sample code
does work (returns 1) for me:

    static inline int X (const char *x) {
      return __builtin_constant_p (x) ? 1 : 0;
    }
    static const char *const fmt = "hello there, %s";
    int foo () {
      return X (fmt);
    }

But it looks like changes on Dec 29 changed that behavior; it now
returns 0.  (Shows how much I use __builtin_constant_p....)


The __builtin_constant_p code seems to be behaving oddly in other
ways, IMHO:

    static char fmt2x[] = "hello there, %s";
    static char *const fmt2 = &fmt2x[0];
    static char *const fmt3 = "hello there, %s";

Here, __builtin_constant_p(fmt3) is 1 and __builtin_constant_p(fmt2)
is 0.  Both are fixed pointer values.

I have just found the documented behavior of __builtin_constant_p with
string literals in inline functions, indicating (again) that it won't
work; I'll check my mail archives and see if there's been discussion
of it before.


(It also doesn't look to me like dcgettext is thread-safe, but maybe
that's not important.)

> > Otherwise, we should probably make sure that people know that -Wformat
> > is useless when GNU gettext is involved.
> 
> It's not useless because a) if you compile without optimization you'll
> get the warnings

Oh, right.  The "let's define things completely differently depending
on whether we're optimizing" approach.  I've never been a big fan of
that.

>  and b) this expression will change.  It predates any
> gcc support.

That doesn't matter to people who are using the code that's out there
now.  When a new version is released, we can change the notice in the
gcc docs.

>   printf (n == 1 ? "%d file" : "%d files", n);

I'd like to see this fixed too, and I may look into it to see how hard
it would be.

> This all produces the same warning.  Not every use of printf-like
> functions is as unsophisticated as the ones you have in your code.

("Unsophisticated" often carries negative connotations I think are
unwarranted in this case; I like "simple" better.)

The question then becomes, how much info do we need to retain about
strings, variables, etc., in order to limit the warning to the
*really* complicated or impossible cases (and, simultaneously, extend
the format checking to the other cases)?