Date: 01 Nov 1999 17:34:44 +0000 From: Randell Jesup <rjesup@wgate.com> To: freebsd-arch@freebsd.org Subject: Compatibility libraries Message-ID: <ybu7lk2glor.fsf_-_@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Peter Jeremy's message of "Tue, 2 Nov 1999 07:40:02 %2B1100" References: <199910312349.CAA02684@tejblum.pp.ru> <ybuu2n7gg1x.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> <99Nov2.073444est.40351@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybu7lk2glor.fsf_-_>