However, I *think* I like the semantics of 'extern inline'
better: use the inline version for the most part but if,
for example, you take the address of the function, use the
actual symbol stat(). But I see that most other fixincs
use static inline.
Huh? This paragraph conflicts with the previous one I quoted. You
don't want extern inline, because you don't want the symbol stat() to
be called - that's your whole problem.
Maybe I expressed myself unclearly. I also may have read the
docs wrong. But this is how I understand it:
extern void foo (void);
extern __inline__ void foo (void) {
some_other_foo();
}
typedef void (*retfn_t)(void);
retfn_t bar (void)
{
foo(); /* Really calls some_other_foo(); */
return foo; /* Returns extern reference to library func foo() */
}
If you compile the above without -O, you only get an UNDEF
for foo in the object file. If you compile it with -O, you
get the UNDEF for both foo and some_other_foo. If you change
extern __inline__ to static __inline__ and remove the first
decl, you only get an UNDEF for some_other_foo.
I thought that the -O case with extern inline was the most
correct. Say for example I have foo() in a library. It's
declared as a weak symbol for __foo. A very common case
with libc functions. A program can legitimately expect to
call foo(), get whatever the header file gives it (for
example, the header could "#define foo some_other_foo").
The same program may also want to return a function pointer
to foo(), and possibly even over-ride the weak library version
with a foo() of their own. The static inline case foils
all of that. The docs hint that 'extern inline' should behave
similarly to a macro, and it does, but only in the -O case.
Gaby pointed out that static inline is the most porttable
and doesn't depend on optimization, so I will go with that.
However, I think it is a mistake (albeit an intentional
one, the docs say that too) that extern inline behaves
differently with -O. I beleive that Gaby's concerns about
intefacing C++ code with C code should not be affected by
extern inline, but I bow to his superior knowledge.
FWIW, compiling with g++, with or without -O, creates
an UNDEF for some_other_foo, and a WEAK for foo. The
only other compiler I have access to, the USL compiler,
behaves the same way with or without -O, and creates
an UNDEF for some_other_foo, and a GLOB for foo. Go
figure.
For the particular problem I am having, I can live with
using static inline, but I *do* think that extern inline
should behave more like a macro in C mode, even without
-O.
Kean
