Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: copying routines, order, and overlap
Message-ID: <10762@mimsy.UUCP>
Date: 22 Mar 88 19:33:34 GMT
References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <1304@ut-emx.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 39

In article <1304@ut-emx.UUCP> wca@ut-emx.UUCP (William C. Anderson) writes:
>... the ndbm(3) routines in 4.3BSD depend upon bcopy() doing the correct
>ordering in cases of overlap.  Luckily, it is simple to do the code correctly.

(This has moved into a new topic)

The ANSI X3J11 draft standard specifies two kinds of block copy
operations.  One (memcpy, I think) is allowed to do the copy in any
order, and must not be given overlapping regions.  The other (memmove)
is required to determine whether the regions overlap and if so, to do
the copy in the nondestructive order.  (I may have the names reversed.
There is not much to distinguish them.)

In 4.2BSD, bcopy was allowed to do the copy in any order.  A chain of
events (which I think I started) resulted in the 4.3BSD bcopy being
constrained to check for overlap.  Note that this is the more general
operation; if you are going to provide only one operation, use the
4.3BSD semantics.*

This does mean that if you move code from 4.3-based systems to 4.2-
based systems, you must be careful about bcopy.

-----
*The test is relatively cheap.  For instance, here is the top of
the 4.3BSD bcopy:

	movl	4(ap),r1	# from
	movl	8(ap),r3	# to
	movl	12(ap),r6	# count
	cmpl	r1,r3
	bgtr	2f		# normal forward case
	blss	3f		# overlapping, must do backwards
	ret			# equal, nothing to do

Eliminating the constraint removes one compare and one branch (and
also the possibility of the final optimisation above).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris