This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
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"
#endif
(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.
386bsd*
bsdi*
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
joseph@codesourcery.com