https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126009
Bug ID: 126009
Summary: memset erroneously indicating "region of size 0"
instead of reporting possibly-null pointer
Product: gcc
Version: 15.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: benwiederhake+zgubccg at posteo dot net
Target Milestone: ---
Created attachment 64873
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64873&action=edit
minimal reproducing example
g++ seems to take the "if (!t)" as indication that t is possibly nullptr. It
would be reasonable to warn about t being possibly null, and it would be
reasonable to simply not warn about it at all. However, "writing 32 bytes into
a region of size 0 overflows the destination" is very misleading.
Please find attached a minimum reproducing example. The error triggers for all
versions that I tested from 11.5 through 15.2.
I encountered this issue in a codebase where it wasn't obvious that
"nullptr-ness" might be the reason for g++'s confusion. So a more helpful error
message would be helpful. Currently, the warning is classified as
stringop-overflow or array-bounds, both are misleading.
Would a patch to change this warning to a "potentially-null-deref" be accepted?
(I don't know how soon I will have any success to get there.)
Note that changing memset to "t->mData[3] = 42;" does *not* seem to trigger any
warning, even with high warnings (-Wall -Wextra -pedantic).
Also, running on Godbolt somehow *doesn't* trigger the issue. Huh, weird.
Different from #36602: I'm reporting a warning
Different from #82076: This doesn't involve any sanitizer
Different from #86345: This is not about insanely high numbers
Different from #98172: Unrelated
Different from #100477: This is not about insanely high numbers
Different from #103483: This is about a possibly-null thing, not a range
Different from #107473: This is not about strncpy at all
Different from #109449: Possibly related, bug report isn't clear to me
Different from #109995: This is not about insanely high numbers
Different from #114178: Probably not related (unless "new" is assumed to be
able to fail by returning nullptr and the generated initialization code calls
memset and memset assumes that "new" cannot fail and later analysis then
complains about the fact that the pointer might be nullptr; but that's too many
assumptions for my taste)
Different from #115056: This is not about an off-by-one miscount, but
"everything is zero for some reason".
Probably belongs to the Meta-Bug: #88443
