Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: > On Tue, 02 Jun 2020 15:55:27 +1000 Daniel Axtens <dja@xxxxxxxxxx> wrote: > >> 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. > > Ah. > >> 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 set. 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. Regards, Daniel
