https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83011
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
Summary|-Wformat-truncation wrongly |-Wformat-truncation=2
|computes length (depends on |difficult to avoid for
|the position of numbers in |non-constant bounds
|the addition) |
--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
There's a difference between
len = 52 * timer_count + 27 + (prefix == NULL ? 0 : strlen(prefix)) + 1;
and
len = 1 + 52 * timer_count + 27 + (prefix == NULL ? 0 : strlen(prefix));
just like there's a difference between
UINT_MAX + 0LU + 1
and
1 + UINT_MAX + 0LU
The former promotes the 1 to unsigned long and evaluates the first addition in
that type (and the constant expression evaluates to 1) while the latter doesn't
promote it and evaluates the fist addition in unsigned long (and the constant
expression evaluates to 0).
The upshot is that the range of len that GCC sees in the first case is [1,
big-number] while in the second it's [0, big-number]. I explained why the
checker warns in the first case. In the second case, calling snprintf with a
zero bound means to essentially have it assume the size is unlimited. So the
checker never warns on this case.
In short, there is no issue with the computation. There is a potential bug in
the program that would occur if (len < strlen (prefix) + 2) were true. In
ILP32 that could happen for example if (timer_count == 82595524) and
(strlen(prefix) >= 20) were both satisfied. In LP64 this can't happen but GCC
doesn't know that (it doesn't know that strlen(prefix) can't be larger than
PTRDIFF_MAX).
Anyway, having said all this I do agree that the warning in this case is too
difficult to deal with and should be adjusted so I'm going to confirm this
report on that basis.
