Re: [PATCH] Fix up one mishandled plural in diagnostics in gimple-ssa-sprintf.c

[Martin Sebor <msebor at gmail dot com>]

On 12/19/2017 11:28 AM, Jakub Jelinek wrote:
> On Tue, Dec 19, 2017 at 11:19:44AM -0700, Martin Sebor wrote:
> > On 12/19/2017 10:58 AM, Jakub Jelinek wrote:
> > > On Tue, Dec 19, 2017 at 10:49:07AM -0700, Martin Sebor wrote:
> > > > Can the math be moved into inform_n (and warning_n) itself?
> > >
> > > No.  I'm against having dozens of inform_n and warning_n etc.
> >
> > The question/suggestion is to change the existing inform_n and
> > warning_n functions to do the math instead of having each caller
> > do it.  (I.e., not add any more overloads.)
>
> The "math" is a mapping from some type (in this case UHWI) to
> some other type (int, used by our *_n APIs), so that it gives the
> same plural forms for known translations.

I understand that.  Presumably this mapping should be the same
for all messages (whether we're dealing with "bytes" or "elements"
or whatever other quantity).

> Are you suggesting we change the type of the *_n APIs to UHWI
> instead?  What if the caller needs something different?  E.g.
> wide_int, widest_int, offset_int, __int128, whatever else?

I'd expect HWI (either signed or unsigned) to work for existing
callers.  There is (unfortunately) no directive to format wide
ints so callers that also format the number (as in "%wu bytes")
in addition to using it to choose a plural vs singular form have
to convert it to an integer as it is(*).

If/when in the future a directive to format an offset_int and
wide_int (and the various flavors of poly_int) is added we can
revise the API to take whatever type is the most appropriate,
or (more likely) add true overloads (i.e., APIs with the same
name but different type) to handle each form.

My "vision" is to have a single warning_n() name (if not
a single function) handle all there nuances so we don't have
to remember to use waning_uhwi_n() and warning_wide_int_n()
and warning_poly_int_n(), etc., or even call
get_plural_form (n), but still get values of all types
formatted optimally and consistently.

Martin

[*] Extending the dollar flag (or coming up with some other
    intuitive notation) to refer to the N argument might be
    a useful enhancement to make the association between it
    and the form of the message explicit:

    inform_n (loc, nbytes,
              "%0$wu byte",
              "%0$wu bytes");

    and avoid the mistake of passing one value as N and another
    as the argument to the numeric directive.