From: Shujing Zhao <pearly.zhao@oracle.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
Paolo Carlini <paolo.carlini@oracle.com>
Subject: Re: [PATCH C/C++] Fix some diagnostics problems
Date: Mon, 07 Jun 2010 09:33:00 -0000 [thread overview]
Message-ID: <4C0CBC24.3030004@oracle.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1006051308570.29272@digraph.polyomino.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]
On 06/05/2010 09:18 PM, Joseph S. Myers wrote:
> 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.
>
Ok. Since there is no obvious requirement to change them, I only take out the
part that fixes the existing 18n problems.
The following is the patch for C frontend.
[-- Attachment #2: ChangeLog1 --]
[-- Type: text/plain, Size: 241 bytes --]
2010-06-07 Shujing Zhao <pearly.zhao@oracle.com>
* fold-const.c (fold_comparison): Remove redundant parenthesis.
* tree-inline.c (expand_call_inline): Pass translated return value of
cgraph_inline_failed_string to diagnostic function.
[-- Attachment #3: part1.patch --]
[-- Type: text/x-patch, Size: 1472 bytes --]
Index: tree-inline.c
===================================================================
--- tree-inline.c (revision 160130)
+++ tree-inline.c (working copy)
@@ -3774,7 +3774,7 @@ expand_call_inline (basic_block bb, gimp
&& cgraph_global_info_ready)
{
sorry ("inlining failed in call to %q+F: %s", fn,
- cgraph_inline_failed_string (reason));
+ _(cgraph_inline_failed_string (reason)));
sorry ("called from here");
}
else if (warn_inline && DECL_DECLARED_INLINE_P (fn)
@@ -3785,7 +3785,7 @@ expand_call_inline (basic_block bb, gimp
&& cgraph_global_info_ready)
{
warning (OPT_Winline, "inlining failed in call to %q+F: %s",
- fn, cgraph_inline_failed_string (reason));
+ fn, _(cgraph_inline_failed_string (reason)));
warning (OPT_Winline, "called from here");
}
goto egress;
Index: fold-const.c
===================================================================
--- fold-const.c (revision 160130)
+++ fold-const.c (working copy)
@@ -8651,9 +8651,9 @@ fold_comparison (location_t loc, enum tr
&& (TREE_CODE (lhs) != INTEGER_CST
|| !TREE_OVERFLOW (lhs)))
{
- fold_overflow_warning (("assuming signed overflow does not occur "
+ fold_overflow_warning ("assuming signed overflow does not occur "
"when changing X +- C1 cmp C2 to "
- "X cmp C1 +- C2"),
+ "X cmp C1 +- C2",
WARN_STRICT_OVERFLOW_COMPARISON);
return fold_build2_loc (loc, code, type, variable, lhs);
}
next prev parent reply other threads:[~2010-06-07 9:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-04 9:39 Shujing Zhao
2010-06-05 13:18 ` Joseph S. Myers
2010-06-07 9:33 ` Shujing Zhao [this message]
2010-06-07 13:27 ` Joseph S. Myers
2010-06-08 4:09 ` Shujing Zhao
2010-06-08 4:13 Shujing Zhao
2010-06-08 10:42 ` Joseph S. Myers
2010-06-08 13:45 ` Gabriel Dos Reis
2010-06-08 19:08 ` Jason Merrill
2010-06-08 19:11 ` Jason Merrill
2010-06-09 3:20 ` Shujing Zhao
2010-06-09 4:39 ` Jason Merrill
2010-06-09 9:23 ` Shujing Zhao
2010-06-09 13:00 ` Jason Merrill
2010-06-10 7:07 ` Shujing Zhao
2010-06-10 13:13 ` Jason Merrill
2010-06-11 6:02 ` Shujing Zhao
2010-06-11 9:33 ` Manuel López-Ibáñez
2010-06-11 9:40 ` Manuel López-Ibáñez
2010-06-11 10:50 ` Shujing Zhao
2010-06-11 11:22 ` Manuel López-Ibáñez
2010-06-12 7:55 ` Shujing Zhao
2010-06-12 13:44 ` Jason Merrill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C0CBC24.3030004@oracle.com \
--to=pearly.zhao@oracle.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=paolo.carlini@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).