Tom Leete wrote:
> Why s/__inline__/inline/g? In current gcc they are
> synonymous keywords. ANSI passed C99 last week, which will
> break gnuish assumptions about 'inline'. I'm campaigning for
> s/inline/__inline__/g.
It's shorter, looks nicer, and the kernel is tied to gcc pretty heavily
anyway.
> I don't understand your extern->static campaign. The two
> have quite different behaviors and should be chosen
> carefully. In particular, taking the address of a 'static
> inline' function prevents its inlining anywhere. In any
> case, inline is only a hint to the compiler.
Taking the address of a static inline function seems rather silly.
But as for "why", using 'static inline' makes the compiler try its best
to avoid the problem of inlining sometimes not getting done, i.e. try
even harder than 'extern inline'.
But you are entirely correct -- each change must be carefully considered
and tested, it's not a simple search-and-replace. Right now I am
hitting major include/linux headers, doing a search-n-replace, and then
testing that change..
Jeff
-- Jeff Garzik | Liberty is always dangerous, but Building 1024 | it is the safest thing we have. MandrakeSoft, Inc. | -- Harry Emerson Fosdick- 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/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:14 EST