Date: Mon, 9 Mar 2009 14:40:42 +0100 From: Stefan Farfeleder <stefan@fafoe.narf.at> To: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> Cc: arch@FreeBSD.ORG, Sam Leffler <sam@FreeBSD.ORG> Subject: Re: C99 inlines Message-ID: <20090309134041.GA23152@lizard.fafoe.narf.at> 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 at 09:55:41PM +1100, 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? With static inline functions you end up with a copy in each object file where the compiler decided to not inline at least one call, with an inline function with external linkage all these copies are coalesced to a single one.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090309134041.GA23152>