alan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
