This is the mail archive of the
mailing list for the glibc project.
Re: Wish for 2002 ...
- From: Felix von Leitner <felix-secaudit at fefe dot de>
- To: "Thomas Bushnell, BSG" <tb at becket dot net>
- Cc: Kaz Kylheku <kaz at ashi dot footprints dot net>, Francois Leclerc <leclerc at austin dot sns dot slb dot com>, Security Audit <security-audit at ferret dot lmh dot ox dot ac dot uk>, Andrew Josey <a dot josey at opengroup dot org>, Tiemann <tiemann at redhat dot com>, libc-alpha at sources dot redhat dot com, Robust Open Source <open-source at csl dot sri dot com>
- Date: Fri, 11 Jan 2002 14:24:17 +0100
- Subject: Re: Wish for 2002 ...
- References: <Pine.LNX.4.33.0201101914240.31242-100000@ashi.FootPrints.net> <email@example.com>
Thus spake Thomas Bushnell, BSG (firstname.lastname@example.org):
> Um, you missed my point, didn't you?
> Why does libc have bcopy, memcpy, strncpy, and all the rest? (Do you
> need a hint?)
Answer: the Single Unix Specification says they should be there.
Your or my personal whims about what should be where do not matter AT
ALL. I can put those functions in my libc, and it would still help
noone. In the contrary, the body of Linux-only code is shockingly
large, because people take glibc and Linux specific functionality for
granted. The BSD people are whining about it all the time.
Now, if you add strl* to glibc (and publicize it enough), people will
start using it and their code will stop working on previous versions of
Linux and commercial Unices. So that would do a great deal of damage to
the world. More non-standards-compliant unportable software will
emerge. And all because one Thomas Bushnell had too much time on his
Thomas, if you think you need to lead a holy crusade to create a fast
version of strlcat, please go ahead. Release the result as
libstrlcat and announce it on Freshmeat.
> 1) These functions exist in BSD libc, which used to be a sufficient
> argument all by itself for why they should in glibc.
> 2) These functions are in growing use by many programs.
What, bcopy? In growing use?
If the foundation for your other arguments is as weak as this, you
should redo your research.
In case this needs to be made any more clear: that is exactly what we
always complain to Microsoft about. They add crap to perfectly good
APIs and with that break compatibility with other platforms. This would
make sense for us if we were a ruthless monopoly trying to crush the BSD
competition. Last time I looked, we weren't.
> 3) Implementing these functions in one place is better than
> implementing them in each of those many programs.
They _still_ need to be implemented in each program.
> So, to summarize:
> 1) We should not add these functions because it will make glibc a tiny
> bit slower. (Linus)
> 2) We should not add these functions because we don't really care
> about tiny improvements in speed. (Kaz)
> Can you pick a single story and keep it straight?
Thomas, we have perfectly good arguments.
You don't have to invent new ones which look easier to ridicule or