Re: Wish for 2002 ...

[Jeroen Dekkers <jeroen at dekkers dot cx>]

On Sat, Jan 12, 2002 at 07:47:52PM -0800, Russ Allbery wrote:
> Jeroen Dekkers <jeroen@dekkers.cx> writes:
> > * 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.

If you think that GNU software is the only software using glibc,
you're wrong. There is more non-GNU software using glibc than GNU
software. Or are those non-GNU programs using a C library I'm not
aware of? I think there are a lot of people who want to run BSD
software (which might use the strlc*() functions) on their GNU systems.

And to quote GNU's glibc page:
" The GNU C library is used as the C library in the GNU system and
most newer systems with the Linux kernel. 

The history of Unix and various standards determine much of the
interface of the C library. In general the GNU C library supports the
ISO C and POSIX standards. We also try to support the features of
popular Unix variants (including BSD and System V) when those do not
conflict with the standards. Different compatibility modes (selectable
when you compile an application) allow the peaceful coexistence of
compatibility support for different varieties of Unix."

The popular used to be BSD4.4 and BSD4.3 when glibc was written, but I
see no reason why not support the current BSDs when there are no
conflicts. Or are those current BSDs no popular Unix variants? They
are even free variants!

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

Thomas already volunteered to write it. Maintaining isn't that a big
problem with glibc's source layout AFAIK. If you write good
documentation I don't think there are much questions.

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

Yes, but why not help those people and let glibc provide the
functions? What's wrong with helping other people, even if they have
another opinion than you?

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

Yes, but we still want to be POSIX compliant. We also want to support
older programs using those function. And IMHO we also should support
programs which used those functions on BSD.

> > * 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*

And what a good arguments do you have here! I want to say that the
speed doesn't change, if you think it will be slower provide some hard
data showing that it's slower. Neither you nor Linus is doing that.

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

I wanted to explain it because there were some people who said we
should not include it for the reason that fixed size buffers are
against the GNU Coding Standards.
 
Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects

Attachment: msg00185/pgp00000.pgp
Description: PGP signature