https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90175
Jozef Lawrynowicz <jozefl.gcc at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jozefl.gcc at gmail dot com
--- Comment #1 from Jozef Lawrynowicz <jozefl.gcc at gmail dot com> ---
(In reply to Roland Illig from comment #0)
> While here, I noticed that the warning message "naked functions cannot be
> reentrant" is never translated properly. This message, and the other ones
> must be enclosed in N_(...).
What is the difference between G_(...) and N_(...)?
I could only find current documentation regarding G_(...) in gcc/ABOUT-GCC-NLS:
> The `G_(GMSGID)' macro defined in intl.h can be used to mark GCC diagnostics
> format strings as requiring translation, but other than that it is a
> no-op at runtime.
r42965 back in 2001 added documentation about N_(...) but it has subsequently
been removed:
> Non-empty description strings should be marked with @code{N_(@dots{})} for
> @command{xgettext}. In addition to the description for @option{--help},
> more detailed documentation for each option should be added to
> @file{invoke.texi}.
Both G_(...) and N_(...) appear sparingly used in the any of the back ends.
Most back ends don't use them at all.
As far as I understand, strings which get passed to warning() or error() or
other functions with arguments ending in gmsgid don't need to be wrapped with
G_() or N_(). From gcc/ABOUT-GCC-NLS again:
> If the parameter name ends with `gmsgid', it is assumed to be a GCC
> diagnostics format string requiring translation, if it ends with
> `cmsgid', it is assumed to be a format string for `printf' family
> of functions, requiring a translation.
So I guess in the case of this message about the "critical" attribute, it
should be reworded and critical wrapped in %< %> but I don't think it needs the
N_() or G_().
The instance when we do have wrapping of messages in G_(...) in msp430.c is
when the string is stored in a variable which is later passed to warning() (see
msp430_attr() for example). I'm guessing this is necessary because the
translation requirement somehow isn't set on the string if it is stored in a
variable before being passed to the function.
