> 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.

I didn't mean to imply it would act as if it were a byte by byte
copy - and thus suitable for replicating patterns,
After all most optimised versions will copy short blocks, indeed
some optimisations [1] copy small blocks in reverse order [2].

If you have aliased memory and are copying from one alias to
the other (with an offset) then you need to know that the copy
won't be done backwards just because the virtual addresses are
a particular way around.
(I had to do this, and found the copy being done backwards...)

	David

[1] Often dis-optimisations....
[2] I'm not sure if these should be allowed, I know one system
where this optimisation got removed between 2 versions, probably
because of the shere size of the unrolled loop.

-- 
David Laight: david@l8s.co.uk