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: <20190206174339.GA19743@archlinux-ryzen>
Date:   Wed, 6 Feb 2019 10:43:39 -0700
From:   Nathan Chancellor <natechancellor@...il.com>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Jon Flatley <jflat@...omium.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michal Marek <michal.lkml@...kovi.net>
Subject: Re: [PATCH] kbuild, LLVMLinux: Don't suppress format warnings

On Wed, Feb 06, 2019 at 09:36:55AM -0800, Nick Desaulniers wrote:
> On Wed, Feb 6, 2019 at 9:32 AM Jon Flatley <jflat@...omium.org> wrote:
> >
> > On Wed, Feb 6, 2019 at 8:45 AM Nathan Chancellor
> > <natechancellor@...il.com> wrote:
> > >
> > > On Tue, Feb 05, 2019 at 05:26:05PM +0900, Masahiro Yamada wrote:
> > > > On Sat, Feb 2, 2019 at 6:10 AM <jflat@...omium.org> wrote:
> > > > >
> > > > > From: Jon Flatley <jflat@...omium.org>
> > > > >
> > > > > gcc produces format warnings that clang suppresses. To keep behavior
> > > > > consistent between gcc and clang, don't suppress format warnings in
> > > > > clang.
> > > > >
> > > > > Signed-off-by: Jon Flatley <jflat@...omium.org>
> > > > > ---
> > > >
> > > > Applied to linux-kbuild.
> > > > Thanks.
> > > >
> > > >
> > >
> > > Hi Jon and Masahiro,
> > >
> > > Just as a heads up, this introduces a ton of warnings (duh). Isn't the
> > > typical plan behind turning on warnings that were disabled to build with
> > > 'W=', fix them all, then turn them on so as not to pollute the build?
> > >
> > > Log file: https://gist.github.com/443db156e56cd3c0f6b21d9d77728d80
> 
> Oh boy, that's a lot.  Too many to fix quickly IMO.
> 
> > >
> > > Note a big chunk of them come from one scnprintf call in
> > > include/linux/usb/wusb.h but still, there are many other warnings that
> > > make quite a bit of noise. Some seem relatively easy to fix, which I
> > > suppose I will try to tackle soon.
> > >
> > > Thanks,
> > > Nathan
> > >
> >
> > Hi Nathan,
> >
> > This was definitely not my intention.
> > I noticed the added warnings this morning and was considering calling
> > for a revert on this patch.
> >
> > The intent was to match the behavior of gcc, as it has -Wformat enabled.
> > It was rather naive of me to assume the behavior of -Wformat would be
> > the same in both gcc and clang.
> > Indeed, it seems gcc is more permissive about what format
> > substitutions it allows.
> >

My guess is that it has something to do with how the compilers
internally handle certain specifier promotions (GCC probably just
silently ignores the 'h' part of the specifier whereas Clang warns) but
I didn't do any actual research into the matter. Probably should before
looking into all of the warnings :)

> > For example passing int to the "%hu" format specifier is fine in gcc
> > under -Wformat but produces a warning in clang.
> > Maybe this was the motivation for adding -Wno-format to clang in the
> > first place.
> 
> Sorry, I'm late to this thread.  What is it reverting; who authored
> the original patch? Was it mka@...omium.org?
> 

This patch is turning on '-Wformat' for Clang, which was disabled in
commit 3d3d6b847420 ("kbuild: LLVMLinux: Adapt warnings for compilation
with clang").

> > This difference is puzzling to me, and I wonder if it's by design.
> 
> Probably; internally let's sync up with the Clang devs to understand
> this difference more.
> 

Yes, I do think it would be a good idea to turn this on eventually but
it'd be wise to understand why Clang emits a warning but GCC doesn't.

> >
> > Considering the whole point of this patch was to sync up this behavior
> > between gcc and clang I am OK with reverting this.
> 
> Is this patch in -next, or has it already hit mainline?  I think it's
> better to revert, then start upstreaming fixes, then re-land it once
> we're warning free.
> 

It's in linux-kbuild/kbuild, it hasn't hit -next yet.

Nathan

> -- 
> Thanks,
> ~Nick Desaulniers

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ