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: <CA+55aFxf6_cA5hTtDGqPU4=DkKz_6OUizhiqge+Xf5u34RxeXw@mail.gmail.com>
Date:	Sun, 19 Oct 2014 16:49:16 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Kirill A. Shutemov" <kirill@...temov.name>
Cc:	Aaro Koskinen <aaro.koskinen@....fi>,
	Andrew Pinski <pinskia@...il.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kernel: use the gnu89 standard explicitly

On Sun, Oct 19, 2014 at 4:10 PM, Kirill A. Shutemov
<kirill@...temov.name> wrote:
>
> IIUC, it's nothing to do with volatile. C11 and above reads
>
>         (rwlock_t) { .raw_lock = { 0 }, }
>
> as compound literal (which is not constant) rather than constant
> initalizer plus a cast.

Ahh. I thought it was the volatile, just because of the "constant"
part and the fact that it looked like the test-case was minimal. But
apparently that was just a red herring.

So it's just the fact that C11 hasn't got the useful GNU extension of
a cast-with-initializer, and then that extension got removed (probably
just an oversight) because people thought that the "standard" C11
initializers were good enough.

And it sounds like this will get fixed (perhaps already is) in gcc anyway.

So maybe we need to do that "--std=gnu89" as a temporary workaround,
but not as long long-term "newer versions are broken".

That doesn't sound too bad. My main objection to the patch was a
"let's try to fix this properly instead", but if the breakage is just
a temporary problem, there's no issue with "properly". Although it
does look like the *placement* of the --std=gnu89 was incorrect in
that original patch, so it needs updating regardless.

AndrewP, mind explaing the other difference you mentioned (ie wrt
"extern inline")? I thought we had already long since ended up
following the gcc semantics (ie use "static inline" if we don't have
an external version somehwre), what exactly changed?

Thanks,

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