On 01/03/13 12:23, Eric Blake wrote: > The elided code was not using _GL_EXTERN_INLINE, but _GL_INLINE. They > have different semantics, but I'm hard-pressed to say _which_ semantics > are right from just those names. Standard C semantics. _GL_EXTERN_INLINE is C99/C11 extern inline. _GL_INILNE is C99/C11 inline. > If I understand correctly, we _want_ > the semantics where the inline function is _always_ inlined and never > emitted as a linkable entry point, but I'd have to refer back to C99 and > the gcc manual to see which use of inline and possible __attribute__ > combinations guarantees that point. Can't be done in Standard C, as far as I know. With GNU C it can be done with __attribute__((__always_inline__)). Why is it important that it not be a linkable entry point? > maybe it's worth adding a name _GL_ELIDABLE_INLINE into > m4/extern-inline.m4 to make it easier to use the results. Sorry, I guess I don't see how this would work. That is, I can see how _GL_ELIDABLE_INLINE would expand to 'inline __attribute__((__always_inline__))' in GNU C, but what would it expand to in Standard C? It can't be expanded to nothing, since you don't want a linkable entry point, and it can't be expanded to 'static', at least not in a header, because the resulting function couldn't be called from an extern inline function. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list