Re: [PATCH 3/5] index-pack: correct "len" type in unpack_data()

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 6, 2016, 16:04 UTC
Message-ID: <xmqqmvluu50w.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACsJy8ASYszXU-ErPas99EpW_J_E-FQVk197W7KqURJge_RBRQ@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 11 quoted lines

> What can I say, gettext is smart. In gc.c we already have this
>
> die(_("gc is already running on machine '%s' pid %"PRIuMAX" (use
> --force if not)"), name, (uintmax_t)pid);
>
> and vi.po shows
>
> #: builtin/gc.c:397
> #, c-format
> msgid ""
> "gc is already running on machine '%s' pid %<PRIuMAX> (use --force if not)"

And translators are expcted to keep "%<PRIuMAX>" in their translated .po files, and whatever translates .po into .mo knows what %<PRIuMAX> should be mapped to?

That is surprising.

On a related but not surprising tangent, I see this example in gettext.info that may be relevant.

       About larger integer types, such as ‘uintmax_t’ or ‘unsigned long
    long’: they can be handled by reducing the value to a range that fits in
    an ‘unsigned long’.  Simply casting the value to ‘unsigned long’ would
    not do the right thing, since it would treat ‘ULONG_MAX + 1’ like zero,
    ‘ULONG_MAX + 2’ like singular, and the like.  Here you can exploit the
    fact that all mentioned plural form formulas eventually become periodic,
    with a period that is a divisor of 100 (or 1000 or 1000000).  So, when
    you reduce a large value to another one in the range [1000000, 1999999]
    that ends in the same 6 decimal digits, you can assume that it will lead
    to the same plural form selection.  This code does this:

         #include <inttypes.h>
         uintmax_t nbytes = ...;
         printf (ngettext ("The file has %"PRIuMAX" byte.",
                           "The file has %"PRIuMAX" bytes.",
                           (nbytes > ULONG_MAX
                            ? (nbytes % 1000000) + 1000000
                            : nbytes)),
                 nbytes);