On Mon, Sep 05, 2005 at 10:52:47AM +0200, Michael Matz wrote:
> Hi,
>
> On Fri, 2 Sep 2005, Adrian Bunk wrote:
>
> > "extern inline" doesn't make much sense.
>
> It does. It's a GCC extension which says "never ever emit an out-of-line
> version of this function, not even if its address is taken", i.e. it's
> implicitely assumed, that if there is a need for such out-of-line variant,
> then it is provided by some other mean (for instance by defining it
> without inline markers in some .o file). Usually there won't be such need
So you agree with my statement that it doesn't make sense because there
are no out-of-line variants?
> as all instances are inlined, in which case the out-of-line version would
> be dead bloat, which you can't get rid of without this extension. And if
> some calls are not inlined then this extension serves as a poor mans
> check, because a link error will result.
In the kernel (with gcc >= 3.1), _every_ inline is forced to
always_inline resulting in gcc aborting with an error if it can't inline
the function.
Therefore any such out-of-line version if it existed would be dead
bloat.
> All in all, it does make sense, and no it's not the same as a "static
> inline", not even if forced always_inline.
It isn't the same, but "static inline" is the correct variant.
"extern inline __attribute__((always_inline))" (which is what
"extern inline" is expanded to) doesn't make sense.
> Ciao,
> Michael.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
