Re: Inline documentation patch...

[craig at jcb-sc dot com]

Looks good!  Minor nits follow.

>+@emph{N.B.}  GNU C cannot guarantee that all functions declared
>+@code{inline} will actually be inlined, even those declared
>+@code{extern}.  If it is you need to guarantee that the code actually

Remove "is".

>+be inserted at the point of use, then there is no other option than to

Probably replace "be" with "is".

>+use a macro and Statement Expressions (@pxref{Statement Exprs}).  If
>+you merely wish to be notified when an inline attempt has failed, then
>+you will be notified with the -Winline option (@pxref{Warning

Put @samp{} around "-Winline", I think.

>+Options}).

Note that one possible problem with the above is that there I don't
think there's any requirement that Statement Expressions be compiled
into separate copies per macro invocation, or anything like that.

I.e. a truly optimizing compiler/linker/loader/runtime combination
(at least compiler/linker, anyway) could find repeated chunks of code
and combine them into single copies to reduce load time and Icache usage,
among other things.  (It could even combine them into distinct
procedures.)  That might not be a problem for the specific cases
being discussed, but for *other* cases apparently permitted by the
above wording, it could someday be.

So do we really want to offer the above as a guarantee, or just say
"...at the point of us, then, for current versions of GNU C, the
most reliable method is to use a macro and..." instead?

        tq vm, (burley)