memcpy

[Doug Gwyn]

In article <BURLEY.90Sep21111221 at world.std.com> burley at world.std.com (James C Burley) writes:
>In article <13914 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>   ...  Some memcpy() implementations
>   have attempted to "do the right thing" (meaning: follow the sequential
>   pick-the-entire-block-up-into-a-temporary-register, then-put-the-
>   temporary-register-contents-back-down-at-the-new-location model) for
>   cases of overlaps, while others have not.
>First off, it strikes me (THUNK!  :-) that my expectation of what memmove
>would do is exactly the opposite of what is desired.  If one wants to use
>a memory move to spew a given set of values (in the case discussed here,
>just one) across memory, and indeed the more-than-one case is not covered
>to my knowledge my memset or any other ANSI function, it seems that one does
>not want to use a memory move that is "smart enough" to do an overlapping
>move the "right" way.

It's true that the original application was attempting a "smear" rather
than a "blit" operation, and my previous comments failed to address that.
Previous arguments about memcpy() have focussed on the block-move model
rather than a smearing model, perhaps because very few people think that
the latter is very sensible.  (Note that there are two different smearing
directions, and that applications for smearing are rather rare.)

To smear a single byte, as in the original application, memset() is
recommended.

>Second, I don't think it is necessary for memmove to actually copy into a
>temporary.

No, that was the block-transfer MODEL, not the implementation.

>I think one can do an implementation similar to the following
>...
>if ((source > dest) || (source + n <= dest))
* Warning * Non-portable pointer comparisons in above line.

You can get away with that in a flat virtual address space, but not in
general.  This is essentially the reason for my doubt that a portable
implementation would be possible.  Since then, I have received e-mail
that points out that a portable implementation would be possible by
using pointer equality tests within a loop over object bytes.  This
would, however, be excruciatingly slow, so it still appears that there
is no PRACTICAL portable implementation method for memmove().