Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!sjsca4!konath
From: konath@sj.ate.slb.com (Kannan Konath)
Newsgroups: comp.lang.c
Subject: Re: memcpy != bcopy (Was Re: bcopy() bzero())
Message-ID: <1990Feb23.225358.375@sj.ate.slb.com>
Date: 23 Feb 90 22:53:58 GMT
References: <11387@attctc.Dallas.TX.US> <4601@orion.cf.uci.edu> <497@thirdi.UUCP> <22599@mimsy.umd.edu>
Reply-To: konath@sj.ate.slb.com (Kannan Konath)
Followup-To: comp.lang.c
Distribution: usa
Organization: Schlumberger ATE, San Jose, CA
Lines: 28

In article <22599@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>In article <497@thirdi.UUCP> peter@thirdi.UUCP (Peter Rowell) writes:
>>WARNING!  memcpy is NOT the same as bcopy!!!!
>>This is the source of an *amazing* array of hard-to-find bugs!
>>bcopy correctly handles overlapping memory moves; memcpy does not.
>
>Beware: some versions of bcopy() do, some do not.  (4.2BSD VAX bcopy()
>handled overlap when copying 65535 bytes or less or when forward block
>moves were correct.  4.3BSD VAX bcopy() always handles overlap.)
>
>For absolute safety, use memmove() (a feature of ANSI X3.159 C).

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.
This problem arose when bcopy() was used in a program that was being
ported to the VMS environemnt.  I am not involved in the porting
directly but when going through the semantics of the different block
copy and block move instructions in the Harbison-Steele manual and the
VMS-C manual I noticed this was not stated explicitly in the latter.  


>In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
>Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris


kannan
konath@sj.ate.slb.com