linux-kernel - Re: [PATCH] kernel: use the gnu89 standard explicitly

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+55aFwGWbRcrRxnmc7JrEZh+25zNVw7_PqQiCThHr1An=C4_g@mail.gmail.com>
Date:	Sun, 19 Oct 2014 17:23:04 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	"Kirill A. Shutemov" <kirill@...temov.name>,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Andrew Pinski <pinskia@...il.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:59 PM, Sasha Levin <sasha.levin@...cle.com> wrote:
>
>> 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?
>
> (Stolen from gcc changelog:)
>
> gnu89: extern inline: Will not generate an out-of-line version, but
>         might call one.
> gnu99: extern inline: like GNU "inline", externally visible code is
>         emitted.
>
> (So what happens is that with gnu99 you end up with multiple definitions
> of the symbol since it was externed from multiple compilation units).

Oh Christ. So this got broken yet again, even *after* they had
documented the old behavior?

Originally, gcc documented that "extern inline" is a good replacement
for a macro. Then, that changed, and "static inline" became the
replacement for a macro, and "extern inline" was to mean that *if* it
gets inlined, that definition is used, but otherwise there's supposed
to be an external non-inlined copy somewhere else (so the inline
definition of the function is basically entirely ignored when not
inlining for one reason or another).

So now we have a *third* semantic of "extern inline", and one that
seems to be entirely inappropriate to *ever* be used in a header file
due to duplicate symbol problems. What a mess.

Maybe we should just specify "gnu89" to avoid these kinds of insane
semantic changes.

                     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/