On 01/03/2013 01:48 PM, Paul Eggert wrote:
Can't be done in Standard C, as far as I know.
Oh well, not worth it then.
With GNU C it can be done with __attribute__((__always_inline__)).
Why is it important that it not be a linkable entry point?
At least in the case libvirt was hitting, multiple files used fwrite, which in turn meant multiple linkable entries for rpl_fwrite were emitted when linking things together; but because they weren't marked 'static', the linker didn't like us. If we are going to have a wrapper inline function in a header, then we want to ensure that the wrapper does not cause duplicate links.
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.
Indeed, that's an annoying limitation. Which goes to show that what we did for fwrite (avoid inline altogether, and instead use GNU C instead of Standard C, to get the workaround we wanted) is really all the best we can do - we have to use a case-by-case analysis of WHY a wrapper is in the header, and either pull the wrapper out of a header and into a real function, or rely on compiler extensions for the cases where the wrapper only makes sense for that compiler. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org