Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!csd4.csd.uwm.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: faster bcopy using duffs device
Keywords: loop unrolling, optimize, hacks
Message-ID: <11014@smoke.BRL.MIL>
Date: 9 Sep 89 13:34:54 GMT
References: <5180@portia.Stanford.EDU> <19473@mimsy.UUCP> <14558@haddock.ima.isc.com> <14174@bloom-beacon.MIT.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 9

In article <14174@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
>(It seems it would have been nice to add this guarantee to memcpy
>rather than cluttering the library with another call...)

There are computers for which memcpy() can be compiled into very efficient
in-line code, while memmove() behavior required considerably more code.
Since there were valid arguments both ways, the committee decided to let
the programmer specify the preferred behavior instead of forcing one of
them on him.