Date: Wed, 03 Nov 1999 10:06:06 -0500 From: "Pedro Fernando Giffuni" <pfgiffun@bachue.usc.unal.edu.co> To: Randell Jesup <rjesup@wgate.com> Cc: freebsd-arch@freebsd.org Subject: Re: Compatibility libraries Message-ID: <38204F5E.3EFDDD9E@bachue.usc.unal.edu.co> References: <199910312349.CAA02684@tejblum.pp.ru> <ybuu2n7gg1x.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> <99Nov2.073444est.40351@border.alcanet.com.au> <ybu7lk2glor.fsf_-_@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jeremyp@gsmx07.alcatel.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38204F5E.3EFDDD9E>