Re: libc build failure

[Roland McGrath]

> Both static and extern functions will can be put into header files so they
> can be used instead of macros. However if static is used, it avoids the
> kind of problems Neal has been having. The only difference is that the
> non-inlined copy of the function will be linked to the C library (for extern
> of a non-inlined copy exists) or to the program's that's including the header
> object code. Is this really such a big difference?

The elements you are overlooking are the reasons `extern inline' was
invented in the first place.  In unoptimized code, a real static function
is generated in each and every .o file that included the header file,
whether or not it used the function.  That is a big difference.  If you are
optimizing and you use `static inline', you get unused function warnings in
every file that uses the header but not the function.  (At the time `extern
inline' was invented, there was no __attribute__ concept at all, so you
couldn't use __attribute__((unused)) as you could now.)

Neal only had a problem because there was a bug in the use of extern inline
in libc.  When using extern inline, you have to know what you are doing and
do it properly.

> I'm not the only one concerned about this, the Linux kernel code used to use
> `extern inline' now they are also using `static inline' in many cases.

The Linux kernel never used extern inline properly, or made any attempt.
Every use of extern inline I have seen in Linux is a bug.  Linus is fond of
ignoring stated proper ways to use features and just relying on tiny quirks
of how the compiler he happened to be using happened to optimize his code
on the day he wrote it.