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