From owner-freebsd-arch Wed Nov 3 6:58:41 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 10CAF14C4C for ; Wed, 3 Nov 1999 06:58:35 -0800 (PST) (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 PAA11760 for ; Wed, 3 Nov 1999 15:58:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA87293 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 15:58:28 +0100 (MET) Received: from bachue.usc.unal.edu.co (bachue.usc.unal.edu.co [168.176.3.20]) by hub.freebsd.org (Postfix) with ESMTP id 1136414CB1 for ; Wed, 3 Nov 1999 06:58:17 -0800 (PST) (envelope-from pfgiffun@bachue.usc.unal.edu.co) Received: from bachue.usc.unal.edu.co ([168.176.3.59]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.6) with ESMTP id AAA328F; Wed, 3 Nov 1999 08:57:14 -0500 Message-ID: <38204F5E.3EFDDD9E@bachue.usc.unal.edu.co> Date: Wed, 03 Nov 1999 10:06:06 -0500 From: "Pedro Fernando Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randell Jesup Cc: freebsd-arch@freebsd.org Subject: Re: Compatibility libraries References: <199910312349.CAA02684@tejblum.pp.ru> <99Nov2.073444est.40351@border.alcanet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FWIW, I submitted a PR with itoa() some time ago. Being an unstandard thing, based on a Borland compiler, I though it could be a good thing for -lcompat. strcpy() probably belongs to this category also, and since we are only talking about one or maybe two functions, a new compatibility library doesn't seem necessary. Another option would be porting glibc (yucks) to FreeBSD. That would cover any linux compatibility requirement ;-). However there have not been real world examples of neither of these being required in UNIX. Pedro. Randell Jesup wrote: > > Peter Jeremy writes: > >> While non-ANSI standard, this particular function has been > >>virtually standard in PC compilers for a Long Time. > > > >I don't have it in front of me, but I'm fairly certain that my > >Amiga Lattice C manual lists it as a Lattice extension. Given > >that (AFAIK) M$ C started as Lattice C, I wouldn't be surprised > >if it started with Lattice. Matthew Dillon or bde (as long time > >compiler writers) might be able to offer further insight into > >its ancestry. > > Yes, I think it did start in Lattice (later SAS, then Lattice > again). I should ask John Toebes, one of the former SAS/Lattice compiler > people. I think a number of other popular DOS/Win/OS2 compilers added > it also. It might have originated there, though I think I remember > a reference to it in Dr. Dobbs in an article by Tom Holub back around > '84-85ish (on a pseudo-Cshell implementation?) > > I seem (vaguely) to remember him saying that stpcpy made a > measurable difference in a pass of the compiler (preprocessor I suspect). > Also this was admittedly on a 7MHz 68000 platform. > > >I don't recall ever seeing it in a Unix library (ignoring Linux for > >the time being) - which is probably more relevant here. > > True. > > >Overall, I would not like to see stpcpy() appear in libc, though I > >have nothing against it being included in some compatibility library. > > I bow to the assembled opinions and agree. I'd thought it was a > bit more ubiquitous than it is, given it's in Linux now. > > So, what additional libraries should we have, and what should be in > them? I don't like the "add the code to each port" solution a lot, since > unless the code is standardized, there's a considerable chance for Stupid > Coding Mistakes, not to mention potentially lots of time for the porter to > write (or track down) the source for various portability functions. Sounds > like a good case for libraries. Alternatively, we could have standardized > source-code libraries for use by porters. The downside is that bugfixes > and implementation updates to match the underlying OS become a PAIN to > integrate; and to a lesser extent runtime-bloat. > > -- > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message