>> FWIW memmove() check for overlapped copies and memcpy() should not

I'd agree with those...

>> (and would be expected to copy 'forwards').

...but not this.  The way in which memcpy copies doesn't matter unless
either (a) the regions overlap or (b) the regions aren't both real
memory (eg, one is a device register area).  In case (b) you should be
using bus_space or something like it; in case (a) I think memcpy's
behaviour should be undefined with regards to what's in the destination
region after the call.

In particular, requiring it to behave "as if" it were a simple forward
copy-bytes loop may prevent the use of hardware acceleration that may
be available but which would potentially violate a spec like that.

Even without blitter hardware, well, consider an implementation whose
core loop copies 32- or 64-bit words on a machine with no alignment
restrictions (eg, VAX "1: movq (r0)+,(r1)+; sobgeq r2,1b").  This would
break the use of a two-byte-forward memcpy to replicate a two-byte
pattern through an area, which is a reasonable thing to do if the spec
is that it copies as if with a forward byte-by-byte loop.

I think the ability to accelerate memcpy that way is more important
than sticking to an exact as-if-forward-byte-loop interface spec.  I
think memcpy has always been specced as undefined if the areas overlap
(or undefined within certain bounds) anyway....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B