https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81163
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The destination buffer at tmpname is 255 (NAME_MAX) bytes wide,
chan->base_filename is defined as char[NAME_MAX] with unknown content, meaning
that it can hold a string up to 254 bytes in length, and cpu is a 32-bit
integer with an unknown value. The warning points out that using "%s%d" with
snprintf to format the arguments into the buffer can result between 2 and 266
bytes. It will be 2 bytes when chan->base_filename is the empty string and cpu
between 0 and 9, and 266 bytes when strlen(chan->base_filename) is 254 and cpu
close to UINT_MAX (formatted as a signed integer).
If the arguments cannot be as long/big as that the string can be constrained
using the precision (e.g., "%.250s" to limit the output of chan->base_filename
to the first 250 characters) and by restricting the range of the integer
(e.g., using %hu or %hhu if cpu can be at most UCHAR_MAX or USHRT_MAX large).
If the integer argument is guaranteed to be in some subrange of its type (say
in [0, 32] ) that GCC can't determine from the code it can be made apparent by
asserting the range in the code or branching to some noreturn function like
abort or panic if it isn't in that range.
Otherwise, if the truncation is, in fact, possible, it's expected that the
caller will detect it by testing the snprintf return value and handling it by
branching on it and taking some action. That will suppress the warning. A
possible truncation that is not handled it's considered a bug and a warning for
it is issued. In this case, the bug would result in creating a file with some
trailing cpu digits missing.
