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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140922153355.GB4510@pd.tnic>
Date:	Mon, 22 Sep 2014 17:33:56 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Cc:	sparse@...isli.org, linux-sparse@...r.kernel.org,
	linux-kernel@...r.kernel.org, Mark Rustad <mark.d.rustad@...el.com>
Subject: Re: [PATCH 0/7] Silence even more W=2 warnings

On Fri, Sep 19, 2014 at 08:29:33AM -0700, Jeff Kirsher wrote:
> The following patches silence over 100,000 warnings in a W=2
> kernel build. This series does most of it by using the compilers
> diagnostic controls. The first patch in the series adds macros to
> invoke the pragmas for those controls. Macros are provided for GCC
> and clang. Although they are highly compatible in this area, macros
> are provided for compiler-specific controls, and there is one
> example that uses a clang-specific control (look for DIAG_CLANG_IGNORE).
> 
> Some missing-field-initializers warnings were resolved using
> the diagnostic control macros simply because so many lines
> would have had to have been changed. At this stage Mark thought 
> about avoiding possible merge issues. If the maintainer would 
> rather resolve them by using designated initialization, just 
> say so.
> 
> The combined effect of this patch series and his other patches
> that did not use these diagnostic control macros was to reduce 
> the number of W=2 warnings from 127,164 to 1,345!

Sorry but I don't see the point of actively adding macros to the code
just so that gcc is happy. There's a reason why a bunch of warnings are
disabled in the normal build and only enabled with the W= switch.

The W= things are supposed to be used when developing code and have the
compiler tell you about *possible* issues. That doesn't mean though that
we have to actively "fix" otherwise perfectly fine code.

Having the need to actively go in and add code so that gcc doesn't issue
obscure warnings is going too far, IMO.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ