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

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

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]