Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Felix von Leitner (felix-secauditfefe.de)
Date: Fri Jan 11 2002 - 07:24:17 CST
Thus spake Thomas Bushnell, BSG (tbbecket.net):
> 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