This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: compiler standards (and/or min gcc version) supported withinstalled headers ?
On Wed, 2 Jan 2013, Carlos O'Donell wrote:
> > Given that the headers are generally meant to support non-GCC compilers, I
> > think all you might gain is elimination of cases specifically for older
> > GCC, so that older GCC uses the same cases as non-GCC. Simply changing
> > __GNUC_PREREQ (2, 95) to __GNUC__ is hardly a gain. (And where the
> > older-GCC case is simply an optimization, or where the older-GCC and
> > non-GCC cases have similar functionality that's not fully conforming, I
> > think a more recent baseline such as 4.1 would be reasonable.)
>
> Why choose 4.1 in particular?
It's a guess about what might provide a good trade-off between simplifying
the code in glibc's headers and providing good support for the range of
compilers people might wish to use to build programs (or testcases, etc.)
using those headers.
2.6.16 for minimum kernel version originated as such a trade-off as well -
removing pre-2.6.16 support got most of the cleanup benefits you'd get
from a newer minimum version, while being an old enough version that it
was unlikely to cause problems for users.
I think there are three questions regarding compiler support for glibc
headers - in all cases, the answers for headers shared by gnulib may be
different from those only used in glibc:
* What is the minimum compiler requirement for using the headers at all?
I think this is C90 (or C++98) plus "long long" in most cases, though C99
can probably be assumed for C99 headers. For gnulib, at least C90, but I
don't know about "long long".
* What do we assume __GNUC__ means, where used without a version number as
a condition for using some feature not in C90? For that, I think 2.7 is
the safe answer - but in general such conditions should go in features.h
or sys/cdefs.h, used to define feature macros, and other headers should be
using the feature macros. For headers shared with gnulib, maybe older
versions are supported and the conditions do need to go direct in the
header rather than using glibc-specific feature macros. (So complex.h
might use __GLIBC_HAVE_BUILTIN_COMPLEX instead of __GNUC_PREREQ directly,
for example.)
* To what extent do the installed headers include optimizations or
not-fully-conforming implementations of some header feature for some GCC
version? That's the issue for which I think a more recent version may
make sense (again, for headers not shared with gnulib).
--
Joseph S. Myers
joseph@codesourcery.com