Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!ames!think!bloom-beacon!hstbme.mit.edu!scs
From: scs@hstbme.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: faster bcopy using duffs device
Keywords: loop unrolling, optimize, hacks
Message-ID: <14174@bloom-beacon.MIT.EDU>
Date: 9 Sep 89 05:20:22 GMT
References: <5180@portia.Stanford.EDU> <19473@mimsy.UUCP> <14558@haddock.ima.isc.com>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 17

In article <14558@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <19473@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>bcopy() should be written in assembly (on most processors), put in
>>a library, and forgotten about...
>
>Yes.  (And it should be called memcpy(), that being the standard name;

Actually, when ANSIifying code containing calls to bcopy, memmove
would be a safer replacement, unless or until you inspect the
code to see if the usage needs an overlap guarantee.  Under 4bsd,
at least (some versions, anyway), bcopy was guaranteed to work
correctly if the source and destination overlapped.  memmove has
this guarantee; memcpy does not.  (It seems it would have been
nice to add this guarantee to memcpy rather than cluttering the
library with another call...)

                                           Steve Summit