Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: "extern inline" purge? was: Re: [PATCH] fix "extern inline" | Date | Wed, 1 Dec 2004 09:43:36 +0100 |
| |
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 <><
[unhandled content-type:application/pgp-signature] | |