This is just a tweak to fix a translation bug introduced by
one of my warnings (calling warning() where warning_n() is
more appropriate), and to enhance warning_n() et al. to do
the n % 1000000 + 1000000 computation so callers don't have
to worry about it.

On 02/14/2018 11:02 AM, Martin Sebor wrote:
On 02/13/2018 02:05 PM, Joseph Myers wrote:
On Mon, 12 Feb 2018, Martin Sebor wrote:

Bug 84207 - Hard coded plural in gimple-fold.c points out one
of a number of warning_at() calls where warning_n() should have
been used.  The attached patch both replaces the calls and also
changes the signatures of the warning_n(), error_n(), and
inform_n() functions to take an unsigned HOST_WIDE_INT argument
instead of int.  I also changed the implementation of
diagnostic_n_impl() to deal with unsigned HOST_WIDE_INT values
in excess of ULONG_MAX (the maximum value ngettext handles) so
callers don't need to.

Saturating to ULONG_MAX is not correct for languages where the plural
depends on n%10 or n%100 (see the various Plural-Forms entries in the .po
files).  If n is too large you want something like n % 1000000 + 1000000
instead to get the correct plural form in all cases.

Thanks.  I've made that change in the attached patch.

I was also hoping to test it, either now if it's easy, or if
it's complicated, sometime in the future but I couldn't find
a .po file where it would make a difference.  I could have
easily missed one but none of those I've looked seems to do
much with the plural forms where such large numbers could
come up.  The strings are either all empty or all look
the same.  Do you happen to know of one where it matters
and a suggestion for how to test it?  I suppose I could
create a dummy .po file with a non-trivial Plural-Forms but
then how would I plug it into GCC to verify (in an automated
test) that the right form is used?


Reply via email to