[Bug middle-end/100477] Bogus -Wstringop-overflow warning on memset

msebor at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon May 10 21:46:11 GMT 2021


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
In C/C++ the size of the largest object is PTRDIFF_MAX - 1 bytes.  This is
necessary so that the difference between the address of its first byte and that
just past its last byte fits in ptrdiff_t.  A number of GCC warnings point out
code that breaks this assumption, including allocations in excess of the
maximum or calls to functions like memset or memcpy that would access more than
the maximum.   None of these warnings considers the conditions that must be
true in order for control to reach the problem statement, so if the statement
hasn't been eliminated from in the IL (i.e., can be seen in the output of
-fdump-tree-optimized or whatever pass the warning runs in) the warning
triggers.  Taking the conditions into consideration and issuing "maybe" kinds
of warnings (like -Wmaybe-uninitialized) is a work in progress but as of now no
warning other thanb -Wmaybe-uninitialized does.

No such distinction as "there's definitely a bug" vs "there may be a bug" is
feasible because there is, in general, no way to identify functions that are
defined but never called, or those that are only called with arguments that
make certain code paths unreachable.  As a result, with few exceptions every
GCC warning is of the latter kind.  If you're interested, the following
two-part article discusses some of the challenges in this area:

https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings/
https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings-part-2/

If the #pragma suppression doesn't work with LTO please report that as a
separate bug.  There's nothing we can do to avoid the warning in this case.


More information about the Gcc-bugs mailing list