This is the mail archive of the
mailing list for the glibc project.
Re: Should --enable-bounded be removed?
> * 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.
Agreed. Feel free to clean it up.
> 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.)
Sure. I just meant to suggest the wiki as a canonical place to keep track.
i.e., put it on the wiki now so we don't forget about it, though I am not
fully sanguine about actively removing support yet.
> 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.
Agreed. I just meant that we don't want to break any existing add-on port
unwittingly. Of course, anybody doing an add-on port ought to complain to
libc-ports if something they relied on breaks or if something is hard to do
in a new port they are writing as an add-on. But people often bend over
backwards with strange kludges before asking for help.