alanwli@gmail.com writes:
>> One thing to watch out for is that the intention may have been to allow
>> the strings to be translated.
> I'm not sure if that's the case. How does one find out?
If the origin of the "variable" format is a constant or set of constants
decorated with gettext_noop(), then this type of edit will have defeated
the intended localization. In the cases at hand, I believe that all but
one of your proposed patches break the desired behavior.
What's worse, I see that Magnus got there before you, and has broken
localization here and in several other places:
http://archives.postgresql.org/pgsql-committers/2008-11/msg00264.php
Magnus, you wanna clean up the mess? And what patch does the "few more"
comment refer back to?
A workable solution that both silences the warning and preserves
localizability is to follow a coding pattern like this:
const char *mymsg = gettext_noop("Some text to be localized.");
...
errmsg("%s", _(mymsg)) // not just errmsg(mymsg)
I would recommend that we do this, because otherwise we are certainly
going to have more breakage from well-intentioned patchers, whatever
Peter's opinion of the merits of the compiler warning might be ;-)
The really nasty cases are like this:
const char *myfmt = gettext_noop("Some bleat about object \"%s\".");
...
errmsg(myfmt, objectname)
where there really is no simple way to convince the compiler that you
know what you're doing without breaking functionality. This is probably
why -Wformat-security doesn't warn about the latter type of usage. It
does kind of beg the question of why bother with that warning though ...
regards, tom lane
