Re: [9fans] bcopy in APE

[C H Forsyth <forsyth@vitanuova.com>]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

memmove(s+1, s, 8);

it's usually desirable that after the copy
s[2] gets what s[1] had in it, not s[0]
(and so on).  just checking the initial pointers
is fractionally cheaper than the full check for overlap, but
is enough to guarantee safety.
i did find that on 386 it was better to do the full
check because the forward copy was much faster,
and the cheap check, though safe, meant that
arbitrarily many copies ended up taking the reverse-copy path,
just because of malloc outcomes (say).

overlapped copy was used on some architectures to
set whole buffers to a value having set the first byte, but it's
otherwise not usually what's desired.

[-- Attachment #2: Type: message/rfc822, Size: 2947 bytes --]

From: northern snowfall <dbailey27@ameritech.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] bcopy in APE
Date: Mon, 15 Sep 2003 03:36:36 -0500
Message-ID: <3F657A14.1090709@ameritech.net>

> My question is, why does the function need to increment or
> decrement at all?


Oh, I get it. Because we're preserving the source vector as best
we can. I was just overthinking. Anyone care to confirm or
elaborate?

> And if there is a specific reason, why does
> plan9's implementation do it opposite of the netbsd?


Aha! I just realized that the destination argument in the
plan9 memmove is the source argument in the BSD bcopy.
And, the memmove call in bcopy (/sys/src/ape/lib/bsd/bcopy.c)
flips the arguments appropriately. Hah, okay. Duh.

Obviously, I need sleep. G'night.
Don

http://www.7f.no-ip.com/~north_

Yes, soon. Just email me if you need something off the site.