Re: libc-2.25.90.pot

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 18/07/2017 14:08, Benno Schulenberg wrote:
> 
>>> The GNU C Library is about to release version 2.26.
>>>
>>> * Complete snapshot of 2.16 release containing `po/libc.pot':
>>> ftp://alpha.gnu.org/gnu/glibc/glibc-2.25-737-g66cd050.tar.bz2
>>
>> I see these changes when compared to the previous POT file:
>>
>> -msgid "\"%s\", line %d: "
>> +msgid "\"%s\", line %"
>>
>> -msgid " (rule from \"%s\", line %d)"
>> +msgid " (rule from \"%s\", line %"
>>
>> Are you sure these changes are intentional?  If yes, then maybe
>> they could use a translator hint, to say what is coming after the
>> last "%"?  Also, since those strings are not marked as c-format,
>> a malicious translator might be able to crash the relevant program
>> by putting in %tralala or something instead of %s?
> 
> Ping?
> 
> Benno

I think these a limitation of xgettext used to generate the pot files.
Both are similar defined:

timezone/zic.c

# msgid "\"%s\", line %"
487           fprintf(stderr, _("\"%s\", line %"PRIdLINENO": "), filename, linenum);

# msgid " (rule from \"%s\", line %"
490                 fprintf(stderr, _(" (rule from \"%s\", line %"PRIdLINENO")")

And 'PRIdLINENO' is defined as 

50 typedef intmax_t lineno;
51 #define PRIdLINENO PRIdMAX

Which means we will get different string encodings depending of how
__PRI64_PREFIX is defined by the ABI.

Both changes came from '92bd70fb' (Update timezone code from tzcode 2017b.) and
from original tz project it seems to get from cc8aec6ecb1ecc (zic: some
integer-width fixups).  TZ commit log seems to indicate this is just a integer
cleanup without original from an actual bug or limitation.

Paul I think we can use default %d for ints for these two specific printf to
make translation work as intended. What do you think?