Path: utzoo!attcan!uunet!pyrdc!pyrnj!rutgers!att!cuuxb!mmengel
From: mmengel@cuuxb.ATT.COM (~XT4103000~Marc Mengel~C25~G25~6184~)
Newsgroups: comp.lang.c
Subject: Re: memcpy vs. memmove (was: Re: Explanation, please!)
Message-ID: <2063@cuuxb.ATT.COM>
Date: 13 Sep 88 21:20:09 GMT
References: <8389@smoke.ARPA> <7039@bloom-beacon.MIT.EDU>
Reply-To: mmengel@cuuxb.UUCP (Marc W. Mengel)
Organization: AT&T, Data Systems Group, Lisle, IL
Lines: 31

In article <7039@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
>In article <8389@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes:
>>Some implementations of bcopy() and memcpy() do guarantee
>>proper handling of overlapping fields.  But not all do, so one cannot
>>count on it if one's trying to write truly portable code.  ANSI C will
>>specify a new function memmove() with this property guaranteed.
>
>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?  
>                                            Steve Summit

To check whether the source and destination overlap, you have to compare
two pointer values.  You can only do this legally ($3.3.8) if the two pointers 
point into the same array/aggregate.  Hence you need memmove() for
shifting items in an array, and memcpy() for moving items between arrays.
Using memmove() on items not in the same array is therefore not guaranteed
to work, as the comparison of pointers not in the same array/aggregate is
undefined.

The issue is that to make memcpy() work the way you want it to, you
need to define pointer semantics for comparison on pointers that don't
point into the same array/aggregate.  Feel free to post a definition
for these semantics, I am sure the various net.hackers out there can
name you a machine that your semantics don't make sense on; or force
pointers to be unusually large objects.
-- 
 Marc Mengel			       
 mmengel@cuuxb.att.com
 attmail!mmengel	
 {lll-crg|mtune|att}!cuuxb!mmengel