This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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]

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


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