Date: 29 Oct 1999 15:58:14 +0000 From: Randell Jesup <rjesup@wgate.com> To: freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <ybug0yui2g9.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Chris Costello's message of "Fri, 29 Oct 1999 13:45:49 -0500" References: <19991029132257.A535@holly.calldei.com> <19991029111352.A87934@dragon.nuxi.com> <19991029132257.A535@holly.calldei.com> <199910291829.MAA89401@harmony.village.org> <19991029134549.B535@holly.calldei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Costello <chris@calldei.com> writes:
>> : I'm seeing more and more of a need for a compat library for
>> : Linux and GNU software in general. Adding unnecessary bloat to
>> : our libc isn't necessary, in my opinion.
>>
>> The problem with this is that it becomes harder to build on FreeBSD
>> because you have to add additional, non-standard libraries to the
>> build process.
> That's the problem. I honestly can't begin to think of a perfect
>way of getting around Linux developers putting kludge after kludge
>on top of poorly written workarounds on top of hacks that were never
>really fully implemented (as far as libc goes). Put their
>functions in our libc and we end up with a bigger, bloated libc.
>Make a new library and cause trouble for people wanting to build
>the latest greatest Linux program on FreeBSD.
stpcpy() (the issue in this case) is something I've seen in
compiler's C libraries since the late 80's/early 90's (if I remember
correctly), if I remember correctly. Quite honestly, it's useful, and
if the library mechanism/source is set up right, only affects programs
that use it, and even then it's what, a dozen bytes or two (at most)?
I remember writing my own version of it (before the Lattice compiler
had it) in '85.
It's handy and improves performance for the cases where it's
used, and it's small. The only issue would be the fact that it's
non-ANSI, but so are 5000 other things in the libraries (system calls,
for example), and maybe that some application has it's own hard-coded
version (thus someone's suggestion to use a weak symbol). IMHO.
I'm not addressing the bigger issue of Linux compatibility.
However, libc bloat doesn't seem to me to be a major problem - at worst
a small amount of disk space, and a (very small) bit more CPU to link.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybug0yui2g9.fsf>