https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85175
--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> --- In general, sizing buffers for the minimum/maximum value of each directive's argument and choosing the appropriate length modifiers (e.g., %hhi for char or %hi for short) avoids these problems. The thinking behind the current behavior at level 1 is that an expression in some known range is a sign that the programmer may have made an effort to constrain the value, while an expression for which we have no range information may have been constrained and we just don't see it. When the known range doesn't constrain the value sufficiently, the warning triggers. An unknown range doesn't. The "fix" for a warning in the former case should in most cases be to simply constrain the variable either by using an appropriate length modifier in the directive or just before the call (e.g., via some form of an assertion or an equivalent of '((x < min || x > max) ? __builtin_unreachable () : (void)0). This works quite well except when the buffer is just big enough and when the warning exposes weaknesses in optimizations and/or unforeseen interactions with other transformations (usually jump-threading or the sanitizers). Rather than weakening the warnings our approach to these problems has been to improve the optimizers. I'm hoping this case can be dealt with the same way but I'm not familiar enough with the EVRP machinery yet to tell if that will be possible. As for -Wformat-overflow=2, an expression in an unknown range is treated as if it had the maximum range of its type. (I suppose we should also have level 3 where ranges are ignored and buffers are expected to be sized only according to argument type. I realize it's not what you're looking for but it would make it straightforward to write safe, warning-free code regardless of optimizations.)
