Andrew Morton <akpm(a)linux-foundation.org> writes:
On Tue, 02 Jun 2020 15:55:27 +1000 Daniel Axtens
> Huh, turns out that we do actually see a similar set of warnings before
> and after this patch, they're just different warnings as a consequence
> of my patch.
> Given that these warnings only show up at W=1, is there any point in
> further supressing them?
I guess not.
So what should we do? Go over the various sites and use memcpy(), each
with a suitably apologetic code comment explaining the reason?
It's a good question.
- We could disable the warning outright or demote it to W=2+. It
doesn't tell us about behaviour that is definitely wrong, just
suspicious, and we have a number of callsites in the kenel using it
in a correct and compliant way. Wstringop-overflow catches
full-on overflows (once Linus reenables it).
- We could keep the warning and patch the callsites. One can make the
argument that changing to memcpy makes the semantics more clear: str*
in C refers to null-terminated strings, and if the string isn't
null-terminated then the str* functions aren't a natural fit for
manipulating it. And it means we get to keep the warning enabled to
catch accidental off-by-ones.
- We could do nothing. If you compile with W=1 there is a known set of
warnings and you're probably more interested in the delta than in the
I think I have a slight preference for patching the callsites and
eventually promoting the warning from W=1 to always on. But I have to be
honest that I'm not going to have time to do it soon, and potentially
not for a few months.