Inline documentation patch...

craig@jcb-sc.com craig@jcb-sc.com
Sun Feb 28 18:15:00 GMT 1999


>Suddenly "inline" anywhere becomes a bug waiting to happen, because gcc
>developers can on a whim decide that they won't do inlining of it any
>more.

Anyone using "inline" thinking it means "force inline" has *always*
written it as a "bug waiting to happen".  Changes to the compiler
don't affect that.

And it's often the case that changes to a compiler can expose bugs
in code long believed to be correct simply because "it works",
even when the compiler changes have no effect on the correctness
of the compiler.

Further, it's often the case that such changes, rather than the
code that has the bugs, are blamed for the bugs being exposed
by programmers who don't understand what compilers are and how
to use them.  Those programmers should, instead, offer to help
clarify the documentation, improve the product, and generally be
happy they're still able to learn new things.

E.g. I understand what computers are and how to use them.  That's
why I don't type "rm foo" to a Linux shell and then, immediately
after seeing the prompt, power off my machine, power it back up,
see "foo" still exists, and complain that "rm" doesn't work as
documented under Linux.  (Or, having noticed that this is a seemingly
reliable way to "undo" a mistaken "rm", I might someday complain
when a new journaling facility in Linux makes that stop working,
causing me to lose files, or maybe just when it seems that, on
random occasions, the trick doesn't work, causing me to blame
the new kernel.  But I don't do this, because I understand
what operating systems can and cannot promise, for the most part.)

Depending on collateral behavior of features is always unwise,
and when you get burnt, you have to put out your own flames,
instead of just spreading them to people who are doing a pretty
fine job IMO.

BTW, I agree that the documentation should be improved to be more
clear, though, having actually read the docs myself, I *never*
believed "inline" meant "forces inlining".

But while I agree with the concept of a special __force_inline__
keyword or attribute, it might not be possible to guarantee it
always succeeds.  In that sense, it should be seen as a fairly
clean way to specify, at a suitable level of granularity, what
"inline" combined with "-Winline -Werror" already specifies.

(Is it then really the case that we're arguing about whether the
*compiler* or the *linker* rejects the code due to a failed
"extern inline"?  Sigh.)

That way, the practical matters that dictate continued compiler
development can still have a choice between producing a fatal
error and producing bad code.

        tq vm, (burley)



More information about the Gcc-patches mailing list