Date: Tue, 10 Mar 2009 14:44:33 -0400 From: David Schultz <das@FreeBSD.ORG> To: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> Cc: arch@FreeBSD.ORG, Sam Leffler <sam@FreeBSD.ORG> Subject: Re: C99 inlines Message-ID: <20090310184433.GA72420@zim.MIT.EDU> In-Reply-To: <20090309105541.GA2464@duncan.reilly.home> References: <20090307103138.GA34456@zim.MIT.EDU> <49B2B139.6010104@freebsd.org> <20090308070924.GA39236@zim.MIT.EDU> <20090309105541.GA2464@duncan.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 09, 2009, Andrew Reilly wrote: > On Sun, Mar 08, 2009 at 03:09:24AM -0400, David Schultz wrote: > > My main motivation is that currently there's no easy way to use > > non-static inline functions that works with both gcc and other > > compilers. > > Please pardon my ignorance: what *is* non-static inline > behaviour? I've only ever used static inlines myself: they're > the only sort that make sense (to me), in the world of standard > C static compilation and linkage. What happens elsewhen? Does > the compiler generate a "real" function with an exportable name > that can be linked-to? Why would you want to do that, when > that's what perfectly ordinary functions do? I can't imagine an > extern inline meaning anything useful unless one can do > LLVM-style link-time optimization. Is that on the cards? > > > Furthermore, even GNU wants to move to using the C99 > > semantics by default. Once that happens, continuing to be > > dependent upon the old GNU inline semantics is likely to cause > > porting headaches. > > Well, we don't want to be depending on non-standard semantics, > if we can help it. Sure. Are we? Where? `static inline' is the easiest to use and understand, and it's the only kind where the old GNU rules and C99 agree. So if you're using `static inline', nothing changes. The relevance of non-static inlines becomes apparent if the compiler decides *not* to inline your function. With static inlines, you get a separate static definition in each object file in this case. With non-static inlines, you can arrange to have the compiler generate an external reference to a single module that defines the function. You could argue that the extra copies that `static inline' implies aren't a big deal, and I'd agree with you. So why bother getting the semantics of `inline' and `extern inline' sorted out? Here are a few reasons: - Sometimes standards require libraries to have an externally-visible version of a symbol, even if the header provides an inline definition. In this case, the compiler should pick up the external version if the function isn't inlined. - As gcc 4.3+ becomes more common in the wild, third-party apps may increasingly assume C99 semantics for inlines, and we have no control over this. - In some situations, you want the compiler to inline a function in a few cases where it matters, and use an external reference everywhere else. For example, bde@ arranged for some of the trig innards of libm to be inlined in sin() and cos() because function calls with floating point are incredibly slow on i386. But for functions like lgamma() that nobody uses, the inlining is pointless.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090310184433.GA72420>