Guidance please: static or extern __inline__

[Kean Johnston <jkj at sco dot 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