Messages in this thread | | | Date | Sun, 19 Oct 2014 17:23:04 -0700 | Subject | Re: [PATCH] kernel: use the gnu89 standard explicitly | From | Linus Torvalds <> |
| |
On Sun, Oct 19, 2014 at 4:59 PM, Sasha Levin <sasha.levin@oracle.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
| |