Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)

[craig at jcb-sc dot com]

>I'm also sorry that almost nobody saw the point of having a macro-like
>inline.

Oh, I think *that* point was plenty clear, and certainly has a lot
going for it, in isolation.  I happen to think adding a feature
to support it is probably more expensive, in the long run, than it's
worth, but perhaps having a site-specific attribute corresponding
directly to `-Winline', meaning "okay to not inline as long as a
warning is issue", wouldn't be too much.

>I don't like duplicating code like in libc (where code duplication
>makes sense - having a "official compiled sequence" to link against, with
>a separate version for inlining for optimization). As it is, I guess
>"extern inline" is just useless for what I wanted to do, and nobody seems
>to have a good alternative that doesn't result in more flamage, so while
>I'm disappointed I'll just shut up and lick my wounds. 

One of the problems is that C doesn't have modules a la Fortran 90 and
Ada.  So you have to resort to putting stuff like this (a function
for which "extern inline" is appropriate) in source code *and* in a
header file, which, to make for only one copy, means one #include file
that both the header and the .c file #include.

I'd recommend macros combined with statement expressions, but I don't
know that statement expressions are really robust enough yet, or
if they ever will be.  (And I'm not saying they're all that well
designed, or that they, or even macros, will always guarantee the
inlining you seem to want.)

Also, I don't think you can get the same degree of argument type-
checking via a statement expression within a macro as via a
function.

        tq vm, (burley)