Path: utzoo!attcan!uunet!sdrc!scjones From: scjones@sdrc.UUCP (Larry Jones) Newsgroups: comp.lang.c Subject: Re: memcpy vs. memmove (was: Re: Explanation, please!) Message-ID: <381@sdrc.UUCP> Date: 13 Sep 88 22:36:46 GMT References: <8389@smoke.ARPA> <7039@bloom-beacon.MIT.EDU> Organization: Structural Dynamics Research Corp., Cincinnati Lines: 32 In article <7039@bloom-beacon.MIT.EDU>, scs@athena.mit.edu (Steve Summit) writes: > I'll probably be disgusted by the answer, but can someone explain > why two functions are needed instead of one? Why not just add > the guarantee to memcpy? In my experience, it's not hard to > implement the correct, bidirectional copy behavior. Did someone > actually manage to convince the committee that there is an > architecture and/or implementer out there that is so badly broken > that the overlap test would significantly slow down programs > which did not need the guarantee? Or is it a code size issue for > potential in-line implementations? (I am aware that a correct > overlap test is not trivial for badly broken architectures such > as the segmented 80x86, but the correct test on those machines is > not really hard or slow, either.) All of the above. Many machines have only a single block move instruction which means that the "backwards" move has to be very inefficient and you need to do a true overlap test (rather than a simple direction test). That could add up to a lot of code to inline, but it would really hurt to not inline if the overlap case never happens. The easiest way for the compiler to know for sure whether the overlap case ever happens is to have different functions for the different cases. Also, the committee received a number of letters noting that there are some fairly common operations where memcpy is the inner loop and so ANY slowdown would be unacceptable (e.g. block moves on bitmap displays). ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@sdrc.uucp 2000 Eastman Dr. BIX: ltl Milford, OH 45150 AT&T: (513) 576-2070 "Save the Quayles" - Mark Russell