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