This is the mail archive of the
mailing list for the glibc project.
Re: Wish for 2002 ...
Jeroen Dekkers <email@example.com> writes:
> To summerize the argument for including them:
> * Those functions are commonly used and exist on BSD and some other
> systems. It's the job of glibc to provide those functions for the sake
> of other people who want to use it. It was a goal of glibc to implement
> the functions from BSD.
I disagree that this is the job of glibc, and I think you're
misunderstanding its goals. I think the primary goal of glibc should be
to provide basic C functionality that's useful when writing GNU software,
and I don't think that strlc*() are in that category.
> * The people who use strlc*() are told with a warning that it's bad to
> use those function.
No, they're not. That's something that you're arguing the glibc
maintainers should use their time to both write and maintain, support,
document, and answer questions about.
> IMHO we should respect the opinion of those people and include the
> functions in glibc.
Respecting their opinions doesn't imply that they have to be in glibc. C
supports multiple libraries.
> * There are a lot of functions in glibc which are broken, some of them
> are even more broken then strlc*() and they even don't have a warning
So clearly development effort should be directed at fixing that situation
before adding anything new; that's a basic software maintenance principle.
> * Glibc gets bigger, but the binaries using strlc*() get smaller and
> probably use a better optimized version of strlc*(). I think it will be
> faster if glibc provides those functions, but certainly it won't be
I think you're obviously wrong here. *shrug*
> * Not including them won't make people use dynamic allocation. There are
> enough fools who don't have strlc*() and use static allocations in
> places where it's unportable and you should use dynamic allocation.
> Using fixed-size buffers for paths for example, as PATH_MAX is optional
> (look in your version of POSIX if you don't believe me) and systems may
> have no limit on the path size. GNU/Hurd is such a system for example.
I think this is a very misguided argument.
Oh well, I'm not a glibc maintainer. I just think that this proposal is a
very bad idea. I've stated my reasons; I won't waste the list's time
further with this discussion.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>