[Bug other/80437] New: large decimal numbers in diagnostics are hard to read

["msebor at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80437

            Bug ID: 80437
           Summary: large decimal numbers in diagnostics are hard to read
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Consider the warning printed for the test case in bug 79929, comment #4:

#include <stdlib.h>
#include <string.h>

char * foo(char *c, int len)
{
  char *p, *n;
  n = malloc(len + 5);
  p = c + 5;
  memmove (c, n, p-c);
  if (p < c)
    memset (n + 5, 32, c-p);
  return n;
}
$ gcc -Wall -O -c bug.c
bug.c: In function 'foo':
bug.c:11:5: warning: 'memset': specified size 18446744073709551611 exceeds
maximum object size 9223372036854775807 [-Wstringop-overflow=]
     memset (n + 5, 32, c-p);

As is evident from the discussion in that bug (and some others), it's hard to
see what the large values correspond to in the source code or how they are
computed.  The same problem exists in all diagnostics that print large values,
including (but not limited to) -Walloca-larger-than, -Walloc-size-larger-than,
-Wlarger-than, and -Wformat-overflow, and in any such warnings yet to be added.

One suggestion that's come is to use a hexadecimal notation for such values
(see bug 79929, comment 12).  That would result in printing the following
instead:

bug.c:11:5: warning: 'memset': specified size 0xfffffffffffffffb exceeds
maximum object size 0xffffffffffffffff [-Wstringop-overflow=]

I'm not sure that this a significant improvement.  Those already familiar with
the -Wstringop-overflow warning will likely understand what 0xffffffffffffffff
in this context means but only because we know the maximum object size limit
(i.e., PTRDIFF_MAX) and realize that all printed values are in the [PTRDIFF_MAX
+ 1, SIZE_MAX] range and thus always consist of 16 hex digits.  Someone who's
seen the warning for the first time will either have to guess or count the f's.
 This is even more likely for the specified size (such as 0xfffffffffffffffb). 
In cases where a much lower limit is specified by the user (e.g., via
-Walloca-larger-than) it's even less clear how to interpret a number in any
base.

I think it's possible to do better.  One approach is to print very large values
in terms of well-known constants such as SIZE_MAX or PTRDIFF_MAX.  For
instance, instead of printing 18446744073709551611 (i.e., -5) print SIZE_MAX -
4.  Another solution might be to print sizes as signed (though that won't help
in the case of the user-specified limit).

Since the problem of how best to present large decimal numbers is general and
applies to all diagnostics, including warnings, errors, and notes, a change to
how these numbers are presented should be brought up for a wider discussion
before it's implemented consistently, for all diagnostics.