This is the mail archive of the 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: Should --enable-bounded be removed?

On Tue, 3 Jan 2012, Roland McGrath wrote:

> > * Some relics of support for pre-C90 compilers such as use of __const 
> > instead of plain const in some headers.
> In installed headers I think we don't want to break -traditional if it
> worked before.  So there is no real reason to change these.

For a long time there has been in misc/sys/cdefs.h:

/* The GNU libc does not support any K&R compilers or the traditional mode
   of ISO C compilers anymore.  Check for some of the combinations not
   anymore supported.  */
#if defined __GNUC__ && !defined __STDC__
# error "You need a ISO C conforming compiler to use the glibc headers"

(see the NEWS for version 2.2:

* Compatibility code for K&R C compilers has been removed from the
  header files.  A ISO C compiler is needed to use the library
  (conforming to either C89 or C99 standard).


So, I think the use of __const really is just a relic of something no 
longer supported.  For non-GCC, it's just a macro defined to const anyway.

> I'm inclined to agree with this, but I'm not really positive that nobody is
> using pre-2.6 kernels.  Let's have something like a wiki page of deprecated
> stuff slated for removal and let it stew a bit there before doing this.

The libc-announce mailing list hasn't really been used much for years, but 
announcing a proposed deprecation there would seem more likely to reach 
anyone who cares (about new libc on very old kernels) but is not on 
libc-alpha than the wiki would.  (That is, wiki list of deprecations may 
make sense, but I don't think they are really going to be a useful way of 
finding out whether people care about the deprecations.)

> > and then most of the case over $os except for the gnu* and linux* cases, 
> > and quite a bit of what follows.
> I'm fine with removing some such stuff if everything that ever worked can
> still be supported by add-ons.

I'd say: we should agree that we want people to be able to control the 
mapping of their OS to sysdeps directories in an add-on, and that if 
someone finds a problem doing this when creating an add-on then we will 
work out a solution or add just the case needed by their add-on to libc 
configure, but there is no need to keep a load of cases for targets most 
of which were obsoleted in GCC years ago and haven't worked as glibc ports 
for years just because someone might hypothetically want to create add-on 
support for those OSes in future.

sunos* | ultrix* | newsos* | dynix*
sysv* | isc* | esix* | sco* | minix* | irix4*

are all unsupported in GCC trunk (and osf* and irix6* are obsoleted, for 
removal for GCC 4.8).

Joseph S. Myers

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