Re: [hnaz-linux-mm:master 169/698] include/linux/string.h:307:9: note: in expansion of macro '__underlying_strncpy'

[Daniel Axtens <dja@axtens.net>]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 02 Jun 2020 15:55:27 +1000 Daniel Axtens <dja@axtens.net> 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