Re: Wish for 2002 ...

[Russ Allbery <rra at stanford dot edu>]

Jeroen Dekkers <jeroen@dekkers.cx> 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
> (yet).

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
> slower.

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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>