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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list