Re: "extern inline" purge? was: Re: [PATCH] fix "extern inline"

[Arnd Bergmann <arnd@arndb.de>]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

On Middeweken 01 Dezember 2004 02:33, Andrew Grover wrote:
> On Wed, 10 Nov 2004 13:55:23 +0900, Yoshinori Sato
> <ysato@users.sourceforge.jp> wrote:
> > Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> > -extern __inline__ int generic_fls(int x)
> > +static __inline__ int generic_fls(int x)
> 
> Along the lines of this patch, can I ask... if a patch were created to
> replace all instances of "extern inline" with "static inline" would
> that be a good thing or a waste of time? I found a 3 year old thread
> (Jul 27 2001, "Re: [PATCH] gcc-3.0.1 and 2.4.7-ac1") where it sounded
> like a good thing to do, but obviously there are some still around.

If anyone uses extern inline in the way that it is intended, i.e.
provide an inline function in a header and an out-of-line version
of the same function in some C file, that breaks.

It would be pointless to use extern inline this way now, since we define 
inline to mean always_inline in the kernel, but gcc will give you a 
compile error when it sees the same function defined both as 'static
inline' and as 'extern'. The correct fix is to convert 'extern inline'
to 'static inline' and at the same time remove any external definitions
of the same function.

Another point that has been mentioned before is that forcing inline
to always_inline is not really a good idea. My personal preference
would be to convert all uses of 'extern inline' that are meant as
'this breaks if it is not inline' to something like 'static 
__always_inline' instead of plain 'static inline'. Then maybe some
day the annotations get good enough to leave the decision
to the compiler for the regular case.

	Arnd <><



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]