> Hi,
>
> Here's a first patch. The only thing it does besides replacing "inline"
> with "__inline__" is to fill in the missing statements which set alight
> the "linux headers and C++" flamefest.
This looks useless. The moving out of ISO C namespace doesn't help, because
it would need to be reserved for C++ compatibility anyways.
Near all interesting (=optimizing) C compilers know about inline, and if
not it can be easily #define'd out. Also the next revision of the C
standard has inline.
What they usually don't deal with is gcc's "extern inline", so
migrating from "extern inline" to "static inline". The reasoning behind
the extern thing seems to be to let ld catch non inlined copies. A much
better way to archieve this IMHO is -Winline (if you can stand the few
warnings for the non-fixable cases - which should be few because with
extern inline they didn't even compile)
I think the kernel header ANSIfication is a doomed project though, because
how do you do a efficient spinlock without inline assembly (and don't say
now "move it out of line")? In 2.2+ you cannot do much without spinlocks.
In 2.0 the same applies e.g. to cli/sti
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/