Re: [RFC PATCH] avoid printing type suffix with %E

[Martin Sebor <msebor at gmail dot com>]

On 11/16/2016 11:34 AM, Jeff Law wrote:
> On 10/26/2016 10:37 AM, Martin Sebor wrote:
> > When formatting an integer constant using the %E directive GCC
> > includes a suffix that indicates its type.  This can perhaps be
> > useful in some situations but in my experience it's distracting
> > and gets in the way when writing tests.
> >
> > Here's an example:
> >
> >   $ cat b.c && gcc b.c
> >   constexpr __SIZE_TYPE__ x = 2;
> >
> >   enum E: bool { e = x };
> >   b.c:3:20: error: enumerator value 2ul is outside the range of
> > underlying type ‘bool’
> >    enum E: bool { e = x };
> >                       ^
> >
> > Notice the "2ul" in the error message.
> >
> > As far as I can tell, Clang avoids printing the suffix and I think
> > it would be nice if the GCC pretty printer made it possible to avoid
> > it as well.
> >
> > The attached patch implements one such approach by having the pretty
> > printer recognize the space format flag to suppress the type suffix,
> > so "%E" still prints the suffix but "% E" does not.  I did this to
> > preserve the existing output but I think it would be nicer to avoid
> > printing the suffix with %E and treat (for instance) the pound sign
> > as a request to add the suffix.  I have tested the attached patch
> > but not the alternative.
> >
> > Does anyone have any comments/suggestions for which of the two
> > approaches would be preferable (or what I may have missed here)?
> > I CC David as the diagnostic maintainer.
> I'm having a hard time seeing how this is a significant issue, even when
> writing tests.
>
> It also seems to me that relaying the type of the constant as a suffix
> would help in cases that aren't so obvious.
>
> What am I missing?

I don't think it's terribly important, more like nuisance.  Tests
that check the value printed by the %E directive (I've been writing
lots of those lately -- see for example (*)) have to consistently
use this pattern:

    \[0-9\]+\[lu\]*

When the type of the %E argument is a type like size_t or similar
that can be an alias for unsigned long or unsigned int, it's easy
to make a mistake and hardcode either

    \[0-9\]+lu

or

    \[0-9\]+u

based on the target where the test is being developed and end
up with failures on targets where the actual type is the other.
Copying test cases exercising one type to those exercising the
other (say from int to long) is also more tedious than it would
be without the suffix.

Beyond tests, I have never found the suffix helpful in warnings
or errors, but I also haven't seen too many of them in released
versions of GCC.  With the work I've been doing on buffer
overflow where size expressions are routinely included in
the diagnostics, there are lots more of them.  In some (e.g.,
in all the -Wformat-length) I've taken care to avoid printing
the suffix by converting tree nodes to HOST_WIDE_INT.  But that's
cumbersome and error-prone, and leads to inconsistent output from
GCC for different diagnostics that don't do the same.

Martin

[*] https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01672.html