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.