archive mirror
 help / color / mirror / Atom feed
From: Daniel Axtens <>
To: Andrew Morton <>
Cc: kbuild test robot <>,, Johannes Weiner <>,
	Dmitry Vyukov <>,
	Linux Memory Management List <>
Subject: Re: [hnaz-linux-mm:master 169/698] include/linux/string.h:307:9: note: in expansion of macro '__underlying_strncpy'
Date: Fri, 05 Jun 2020 20:35:21 +1000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Andrew Morton <> writes:

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

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.


      reply	other threads:[~2020-06-05 10:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-30 10:07 [hnaz-linux-mm:master 169/698] include/linux/string.h:307:9: note: in expansion of macro '__underlying_strncpy' kbuild test robot
2020-06-02  1:04 ` Andrew Morton
2020-06-02  3:26   ` Daniel Axtens
2020-06-02  3:53     ` Daniel Axtens
2020-06-02  5:55       ` Daniel Axtens
2020-06-02 19:16         ` Andrew Morton
2020-06-05 10:35           ` Daniel Axtens [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).