On Thu, Jul 28, 2005 at 11:31:55AM -0700, Kean Johnston wrote:
> >>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.
Which is what you want. Your symbol stat() is a legacy interface that
should not be used by new programs. Any alternative that allows you to
generate an undefined reference to stat is a bad alternative, because
it will call the legacy function from new code.
--
Daniel Jacobowitz
CodeSourcery, LLC
