On 10/5/20 7:12 PM, Martin Sebor wrote:
It the future, I would even like to remove the specific range the
ranger was able to compute from the error message itself. As will
become obvious, the ranger can get pretty outrageous ranges that are
entirely non-obvious by looking at the code. Peppering the error
messages with these ranges will ultimately just confuse the user. But
alas, that's a problem for another patch to solve.
I agree that when it comes to sizes where just one bound of the range
is used to decide whether or not to warn (the lower bound in the case
of most warnings but, as the example above shows, the upper bound for
-Walloca-larger-than=), printing multiple subranges is unnecessary
and could easily be confusing. Even printing the very large bounds
(in decimal) in the warning above may be too much. At the same time,
simply printing:
warning: argument to ‘alloca’ may be too large
and nothing else wouldn't be helpful either. (Though it would make
the alloca pass real simple ;-) It's a matter of deciding what
the right amount of detail is in each instance and choosing the best
representation for the values included in it (small values are okay
in decimal, larger values may be better formatted in hex, or involving
well-known symbolic constants like INT_MAX or PTRDIFF_MAX). But
different people have different ideas about how much detail is enough
and what presentation is best. Rather than each of us imposing our
individual preference on all users and ending up with arbitrary
inconsistencies between warnings we should design them so that their
output can be customized. If I like to see the full ranges in warnings
in decimal I should be able to ask GCC to do that. If I just care about
the high level details (say just the more important bound) and prefer
hex for large numbers there should be a way to do that too. It's just
a matter of adding a %R or some such to the pretty-printer to format
a range and exposing an option that will let users choose the format.
(It still leaves room for us to argue about the defaults ;)
Sure, some general shared infrastructure for reporting errors involving
ranges would be nice, inasmuch as the testcases do not test for specific
ranges since those are liable to change from release to release.
Aldy
