bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Translatable strings not marked 'c-format'


From: Ask Hjorth Larsen
Subject: Re: Translatable strings not marked 'c-format'
Date: Tue, 19 Dec 2017 01:17:54 +0100

Hi,

I reported this issue a year ago, but I think it was unfortunately
never resolved.  Please allow me to recap:

Some strings in bfd contain format substitution codes like %A and %B.
Translators will translate these messages and expect gettext to
produce errors if any syntax error is made.  But %A and %B are not
official "printf" substitution codes, so gettext will not produce any
error even if the translator makes a mistake.  Any such mistake will
go undetected, and is likely to cause a segfault or something
similarly nasty once the substitution codes are expanded.

To solve this problem, BFD should either use only the formatting codes
of printf (translation errors will be detected automatically) or avoid
exposing any strings with %A and %B to translators.

The solution is probably to change the strings as follows:

"%B: TLS transition from %s to %s against `%s' at 0x%lx "
       "in section `%A' failed"),

--->

"%s: TLS transition from %s to %s against `%s' at 0x%lx "
       "in section `%s' failed"),

and then appropriately include the strings that %A and %B would evaluate to.

Examples:

Here a translator mistakenly translates %B to %s:

#: elf32-arm.c:6933
msgid ""
"%B(%s): warning: interworking not enabled.\n"
"  first occurrence: %B: thumb call to arm"
msgstr ""
"%s(%s): aviso: no se activó la interoperabilidad.\n"
"  primer suceso: %B: llamada thumb a arm"

Here a translator makes use of printf ordering features to reorder the
substitutions, but I am not sure that this is supported at all by the
BFD substitution mechanism:

# les deux %s sont des noms de processeurs
#: elf32-rl78.c:1218
#, c-format
msgid "RL78 ABI conflict: cannot link %s file %B with %s file %B"
msgstr ""
"Conflit d'ABI RL78: ne peut lier le fichier %2$B pour %1$s avec le fichier "
"%4$B pour %3$s"

Here a substitution is forgotten:

ru.po L3356
  %B %A
  %A
#: libbfd.c:863
msgid "%B: unable to get decompressed section %A"
msgstr "Ошибка в dwarf: не удалось получить расжатый раздел %A"

I don't know what the actual runtime consequences of these errors are,
but I would not be surprised if it is pretty bad.

Best regards
Ask

2016-10-20 17:03 GMT+02:00 Ask Hjorth Larsen <address@hidden>:
> This is the number of errors I find:
>
> Summary
> =======
> da.po: 0 warnings / 1480 messages
> es.po: 1 warnings / 1461 messages
> fi.po: 1 warnings / 1478 messages
> fr.po: 2 warnings / 1347 messages
> id.po: 0 warnings / 880 messages
> ja.po: 2 warnings / 1017 messages
> ro.po: 0 warnings / 605 messages
> ru.po: 2 warnings / 1347 messages
> rw.po: 0 warnings / 2 messages
> sr.po: 0 warnings / 1457 messages
> sv.po: 0 warnings / 1400 messages
> tr.po: 0 warnings / 646 messages
> uk.po: 5 warnings / 1314 messages
> vi.po: 3 warnings / 1342 messages
> zh_CN.po: 0 warnings / 215 messages
>
> However I don't know if the test logic is sufficient to detect all errors.
>
> http://dcwww.camd.dtu.dk/~askhl/files/warnings.txt
> http://dcwww.camd.dtu.dk/~askhl/files/bfd-stringcheck.py (requires pyg3t)
>
> Best regards
> Ask
>
>
> 2016-10-20 16:34 GMT+02:00 Ask Hjorth Larsen <address@hidden>:
>> Hi Nick
>>
>> I just tested a message like this:
>>
>> #: coff-sh.c:2780 cofflink.c:2964
>> #, c-format
>> msgid "%B: illegal symbol index %ld in relocs"
>> msgstr "%A: advarsel: illegalt symbolindeks %ld i relokeringerne"
>>
>> Note how the translation contains an erroneous %A instead of the correct %B.
>>
>> This is accepted by msgfmt.  Thus, the c-format flag cannot validate
>> these codes.  It also accepts the message if %A or %B is omitted.
>>
>> The reason why msgfmt does not recognize them is that the %A/%B codes
>> are defined by the error handler (bfd.c around line 600).   Meanwhile,
>> msgfmt is only aware of the codes of printf.
>>
>> I see "/* Invoking %A with a null section pointer is an internal
>> error.  */", followed by abort(), which means that superficially valid
>> translation files can very easily result in abort() or possibly buffer
>> overruns.
>>
>> My recommendation is to use the same string codes as printf.  Then
>> faulty translations will be rejected by translationproject.
>>
>> I wrote a script to verify existing translations on the web page, and
>> those that I tested had at least a few errors each.
>>
>> Best regards
>> Ask
>>
>>
>> 2016-10-20 12:47 GMT+02:00 Nick Clifton <address@hidden>:
>>> Hi Ask,
>>>
>>>> Do you know when the translation
>>>> templates on translationproject.org will be updated?
>>>
>>> On translationproject.org - no.  But I have just updated the
>>> bfd.pot template in the binutils source repository (which I
>>> forgot to do yesterday, sorry).
>>>
>>> Cheers
>>>   Nick
>>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]