Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!stl!scott
From: scott@stl.stc.co.uk (Mike Scott)
Newsgroups: comp.lang.c
Subject: Re: memcpy != bcopy (Was Re: bcopy() bzero())
Message-ID: <2725@stl.stc.co.uk>
Date: 2 Mar 90 16:45:35 GMT
References: <11387@attctc.Dallas.TX.US> <4601@orion.cf.uci.edu> <497@thirdi.UUCP> <22599@mimsy.umd.edu> <1990Feb23.225358.375@sj.ate.slb.com> <1990Feb24.233833.14129@utzoo.uucp>
Sender: news@stl.stc.co.uk
Reply-To: "Mike Scott" <scott@stl.stc.co.uk>
Organization: STC Technology Limited, London Road, Harlow, Essex, UK
Lines: 27

In article <1990Feb24.233833.14129@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <1990Feb23.225358.375@sj.ate.slb.com> konath@sj.ate.slb.com (Kannan Konath) writes:
>>In the VAX-VMS-C manual,  it states that memmove() has exactly the same
>>functionality as  memcpy().  Does that mean memmove() does not handle
>>overlapped moves or does that mean memcpy() handles overlapped moves.
>
>ANSI C memcpy must not be handed overlapping arguments, whereas ANSI C
>memmove is required to handle them correctly.  How this corresponds to
>VAX VMS C is another question entirely.

from the VAXC 3.0 manual:

	" In VAXC, memmove and memcpy perform the same function.
	Programs that require portability should use memmove
	if the area pointed at by ... could overlap the area
	pointed at by..."

So the implication is that both functions cope 'properly' with
overlapping objects on VMS.




--
Regards.    Mike Scott       STL, London Road, Harlow, Essex  CM17 9NA, UK
scott@stl.stc.co.uk <or> ...uunet!mcsun!ukc!stl!scott <or>
PSI%234237100122::SCOTT        phone +44-279-29531 xtn 3133.