C99 inlines

[David Schultz]

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.