Marcin Dalecki - Re: Clean up extern inline (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

WiadomoÅÄ napisana w dniu 2007-02-02, o godz08:56, przez Jakub Jelinek:

IMHO gnu_inline attribute should be kept too, glibc and other library
installed headers need to be usable in all compilation modes and changing
everything to static inline is not desirable.

IMHO opinion someone should be given a good spanking for a library pretending
to be a C library, which in fact isn't written in C, is more than good for it's
sanity relying on every detectable obscure feature of a particular compiler
and compiler version in it's futile, attempts at micro-benchmark- optimizations
and successful endurance of maintainability by only a narrow class of "highest
priests" at a particular location. The world doesn't revolve around it and as
anything evil (and the glibc is evil) - it should get the adequate treatment by ignorance
of it's bitter winning. :-)Don't think I'm right? So please realize that the Linux kernel did get smoothly
around the issue.

As ISO C99 inline semantics vs.
GNU89 inline is not just about swapping the meaning of inline vs. extern
inline, but also in ISO C99 semantics adding weird requirements that there
can't be even any prototype with extern keyword the uglification of the
headers would be unacceptable (and, furthermore, any app that would add
their own prototype with extern keyword for a standard function would
have a potential to break, depending on whether glibc decided to inline
optimize it or not). With -fgnu89-extern-inline addition a macro which
differentiates both modes is a necessity (without it checking for
GCC >= 4.3 and __STDC_VERSION__ >= 199901L was enough to detect ISO C99
semantics and gnu_inline attribute presence).

Yeah... that's the glibc way - pretending to be "portable". Wouldn't it bee
just too easy and tempting to say that starting with glibc version XX you
will have to use compiler version YY?! In fact that the reality already anyway in respect of
the linux kernel version supported.

Jakub

â Marcin Dalecki â

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]