Re: [PATCH C/C++] Fix some diagnostics problems

["Joseph S. Myers" <joseph@codesourcery.com>]

On Fri, 4 Jun 2010, Shujing Zhao wrote:

> Hi,
> 
> This patch is to cleanup the codes that pass ("%s", message) to diagnostic
> functions, such as error, warning etc. If there some format specifiers in
> 'message', they would not be recognized. If it need be translated, 'message'
> need be wrapped with _() explicitly, while 'message' could be translated in
> diagnostic functions. I thinks pass the 'message' directly to those functions
> would be better.

The Ubuntu etc. people enabling -Wformat-security by default will dislike 
this sort of change.  I disagree with their choice, but it should be 
possible to fix i18n issues in a way that is simultaneously friendly to 
-Wformat-security - in particular, including strings directly in 
diagnostic function calls whenever possible so that they can actually be 
checked at compile time.

This patch suffers from doing far too many things at once.  Some bits 
might be OK, but various parts are wrong, meaning the whole patch has to 
be rejected.  Please submit patches that do just one thing and cannot 
sensibly be subdivided into smaller patches.

As examples of the things done wrong, strsignal returns a *string* that is 
not a *format string* and that it is definitely incorrect to treat as a 
format string.  %e and %n specs are not documented (in the comment in 
gcc.c that documents specs, or in the unfortunate duplicate documentation 
in invoke.texi) as taking format strings; if you change the 
implementation, you must change the interface documentation.  Likewise for 
other cases of action at a distance in this patch: if you change something 
from a verbatim string to a format string at the site where the string is 
called, you must make sure the interface documentation describes this 
change, and that the relevant strings are marked as gcc-internal-format in 
gcc.pot to indicate this to translators, and confirm that you have checked 
that this is appropriate for all callers.

-- 
Joseph S. Myers
joseph@codesourcery.com