Guidance please: static or extern __inline__

[Kean Johnston <jkj@sco.com>]

Hi everyone,

I've run into a little SNAFU with my porting work. In my
fixincludes changes I changed all forms in the header files
of (using stat as an example):
   static int
   stat(const char *__p, stat_t *__s)
   {
     return _xstat(_STAT_VER, __p, __s);
   }

to:
   extern int stat (const char *__p, stat_t *__s);
   extern __inline__ int
   stat(const char *__p, stat_t *__s)
   {
     return _xstat(_STAT_VER, __p, __s);
   }

 From reading teh docs it seems like 'extern __inline__' was
the way to go for this type of header file trickery. However,
it caused a problem bootstrapping the compiler, becuase the
first stage doesn't have -O, so any calls to stat() actually
go to the library routine called stat(), which is an old,
deprecated stat that can't deal with, say, 32-bit inodes or
uid_t's etc, and various programs like fixincludes then
fail to stat files.

If things are compiled with -O, everything works fine,
becuase _xstat, which is what I really want, is called. If
I change the extern __inline__ to static __inline__, it
works correctly, even without optimization.

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.

So my question is in two parts I guess:
a) Which is the better thing to use in a header file for
    this type of function mapping? static or extern inline?
b) If its extern inline, is there a way to force the inline
    expansion even when not using -O (and without command
    line options). I wouldn't want users to get nasty
    surprises if they just used 'gcc -o foo foo.c'.

Any advice and guidance greatly appreciated.

Kean