https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90041
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-04-11
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, we have one.
But the problem is that actually the %e or %n strings in the specs are not
gcc-internal-format, they are printed using:
case 'e':
/* %efoo means report an error with `foo' as error message
and don't execute any more commands for this file. */
{
const char *q = p;
char *buf;
while (*p != 0 && *p != '\n')
p++;
buf = (char *) alloca (p - q + 1);
strncpy (buf, q, p - q);
buf[p - q] = 0;
error ("%s", _(buf));
return -1;
}
break;
case 'n':
/* %nfoo means report a notice with `foo' on stderr. */
{
const char *q = p;
char *buf;
while (*p != 0 && *p != '\n')
p++;
buf = (char *) alloca (p - q + 1);
strncpy (buf, q, p - q);
buf[p - q] = 0;
inform (UNKNOWN_LOCATION, "%s", _(buf));
if (*p)
p++;
}
break;
and so no % is recognized in those strings at all. Furthermore, po/exgettext
just marks all those untranslatable if they contain any % characters:
if (index(msgid, "%") != 0) continue
Not really sure if we want to change the spec handling incompatibly at this
point (allow %<, %>, %', %% in there, start using them and tweak the above so
that it is error (buf) or inform (buf). As the spec file is something that can
be overridden by the user, if we do such a change, it might be safer to verify
the strings that they only contain the argument-less gcc-internal-format %
format specifiers, because otherwise one could just use gcc -specs=myspecs
and there have somewhere {whatever:%ecrash me%I%G%s%s} and get an ICE from the
compiler or driver.
