🚀 go-pugleaf

In article <1990Sep19.021418.11574@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes:
>Is this a bug on the Sparc,
>or is memcpy not fully specified?

Neither one, really.  The implementation of memcpy() is not specified,
but its functional behavior is.  The objects fed to it as source and
destination are required to not overlap.  If they do overlap, what
happens will depend on details of the memcpy() implementation.  In fact
the naive implementation would work for overlap in one direction but
not for overlap in the other direction.  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.  Sometimes the available
architectural support is a factor in determining the "preferred"
implementation, since the hardware may support fast block moves that
don't work according to the simple model.

X3J11's solution was to require conforming implementations to provide
both memcpy(), which is not required to conform to the simple model,
and memmove(), which IS required to conform to the simple model (and
therefore is the function that should be used when overlap is possible).
In many implementations, memcpy() will be implemented merely as an
alternate entry point for memmove(), but in others memcpy() will have
its own separate (presumably somewhat faster) implementation.

Since memmove() is a recent invention, many existing C libraries do not
yet provide it.  I think there have been public-domain implementations,
but I doubt that a fully portable one would be possible due to the lack
of a portable way to determine whether or not the two objects overlap.