Date: Fri, 29 Oct 1999 15:13:17 -0500 From: Chris Costello <chris@calldei.com> To: Randell Jesup <rjesup@wgate.com> Cc: freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <19991029151317.E535@holly.calldei.com> In-Reply-To: <ybug0yui2g9.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> 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> <ybug0yui2g9.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 29, 1999, Randell Jesup wrote: > 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. First it's stpcpy, then GNU getopt, then ... > 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. The bigger issue of Linux compatibility is essentially what this is leading into. Currently the biggest users of stpcpy are Linux applications. Frankly it's hard enough at this point to deal with problems with the GNU getopt (awfully difficult to port programs using GNU getopt without replicating the getopt() code from glibc). At the same time, there are dozens of other Linux compatibility issues. Putting all these new foreign library calls into libc is not the solution unless we're interested in a larger library. The argument "hardware is cheap" is not valid. -- |Chris Costello <chris@calldei.com> |Never test for an error condition you don't |know how to handle. - Steinbach `------------------------------------------- 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?19991029151317.E535>