This is the mail archive of the
mailing list for the glibc project.
Re: Wish for 2002 ...
Thomas Bushnell, BSG <email@example.com> writes:
> Consider: if it isn't in glibc, it basically has to get added to
> autoconf. One way or the other, the function is going to be part of the
> GNU Project, and it's going to have to be maintained.
autoconf contains no user C code, nor do I see any reason why it would
ever include strlcat and strlcpy implementations.
> Moreover, it seems really clear to me that making autoconf the fallback
> library for the functions that could be in glibc but aren't results in
> making those functions that much harder to maintain well.
autoconf is not a fallback library.
There have been discussions on the autoconf list about creating such a
fallback library as a separate project, but the obvious initial goal would
be to cover POSIX and X/Open functions that may be missing on some hosts,
not to support non-standard functions that can be handled other ways.
> One case of this is the optimization issue I mentioned earlier, but more
> to the point: whatever maintenance cost you see as being imposed by
> adding the function to glibc will be necessarily borne by autoconf, and
> in a way that is much more brittle and imposes much more hassle on all
> the related developers.
It is far from obvious to me that the autoconf project need ever care
about these functions.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>