From owner-freebsd-arch Fri Oct 29 13:13: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B9F7415534 for ; Fri, 29 Oct 1999 13:13:01 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA28320 for ; Fri, 29 Oct 1999 22:13:00 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA40897 for freebsd-arch@freebsd.org; Fri, 29 Oct 1999 22:12:59 +0200 (MET DST) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id D36921559A for ; Fri, 29 Oct 1999 13:12:32 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FKD00L2MS4J9S@mta4.rcsntx.swbell.net> for freebsd-arch@FreeBSD.ORG; Fri, 29 Oct 1999 15:12:20 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id PAA01189; Fri, 29 Oct 1999 15:13:18 -0500 (CDT envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Fri, 29 Oct 1999 15:13:17 -0500 From: Chris Costello Subject: Re: stpcpy() In-reply-to: To: Randell Jesup Cc: freebsd-arch@freebsd.org Reply-To: chris@calldei.com Message-id: <19991029151317.E535@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i X-Operating-System: FreeBSD 4.0-CURRENT (i386) 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> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 |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