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.