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: <542419CB.3090902@suse.cz>
Date:	Thu, 25 Sep 2014 15:34:03 +0200
From:	Michal Marek <mmarek@...e.cz>
To:	Behan Webster <behanw@...verseincode.com>
CC:	ak@...ux.intel.com, yamada.m@...panasonic.com, hpa@...ux.intel.com,
	linux-kernel@...r.kernel.org, sam@...nborg.org,
	Mark Charlebois <charlebm@...il.com>
Subject: Re: [PATCH] kbuild, LLVMLinux: Add -Werror to cc-option to support
 clang

On 2014-09-24 20:50, Behan Webster wrote:
> On 09/24/14 05:07, Michal Marek wrote:
>> On 2014-09-23 21:28, behanw@...verseincode.com wrote:
>>> From: Mark Charlebois <charlebm@...il.com>
>>>
>>> Clang will warn about unknown warnings but will not return false
>> You mean unknown options, right?
> 2 kinds of options: flags and warnings. clang used to merely warn about 
> unused/unsupported flags/warnings. It now returns errors for unknown 
> flags, but not warnings (unless you specify -Werror).

Ah, unknown warning options. Now I understand.


> Getting clang to error on unused flags wasn't trivial (this change broke 
> a lot of builds apparently). Fortunately we weren't the only ones who 
> wanted it to behave like gcc in this case. I think it's going to be 
> *much* harder to do the same for warnings. The argument given by 
> supporters of the current situation is that if a warning isn't 
> supported, why break the build? *sigh*

I guess the reason to accept unknown warnings opentions is compatibility
with Makefiles with hardcoded gcc-isms. BTW, GCC at some point started
to ignore unknown -Wno-* options, for everyone's good of course. That's
why we ended up with the cc-disable-warning function. If -W* options for
clang need special care, then it might be a good idea to introduce
cc-warning with the conditional -Werror for clang. There are not that
many places where we add warnings, so the patch would be still short.
That way, the possible silent failure is limited only to warning options
with clang, which is not such a big deal.

Michal
--
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