lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72kseYacgu91NuDGaH1cb+9Jind=0bAt-7baPi28YGbgsQ@mail.gmail.com>
Date:   Thu, 20 Sep 2018 18:28:20 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Andi Kleen <ak@...ux.intel.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-next <linux-next@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: linux-next: disabling -Wstringop-truncation

Hi Stephen, Andi, (Linus),

On Fri, Aug 31, 2018 at 3:17 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Aug 30, 2018 at 3:07 PM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>>
>> I am now mainly using gcc v8.2 for my builds and -Wstringop-truncation
>> causes so many warnings that I am sure to miss others, so I have
>> applied the below to my fixes tree until the noise reduces.
>
> Applied.
>
> If people want the warning with W=xyz, then this is still the correct
> patch, and we should add a line to re-enable it in
> scripts/Makefile.extrawarn.

For reference, I am sending the v5 of the Compiler Attributes series
with the __nonstring patches appended on top, and I am adding the
warning back as well, on W=1.

I think W=1 is better: there are not that many warnings compared to
those in W=2. AFAIK, it is relatively easy to achieve a clean W=1 (and
most code should at least try be W=1 clean, no?). Also, note that now
people can use __nonstring to suppress that warning (if applicable);
and that using properly __nonstring can detect even more problems
(i.e. adding __nonstring may trigger additional warnings, e.g.
-Wstringop-overflow); so I think we should encourage the use of
__nonstring.

Cheers,
Miguel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ