[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] fwrite: silence __wur without using inline



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]