Portability of some overlapping strcpy or memcpy calls

[Doug Gwyn]

In article <338 at wjh12.harvard.edu> kendall%saber at harvard.harvard.edu (Samuel C. Kendall) writes:
>	memcpy(p, p + M, N)
>... overlapping copy, ...
>I'm interested in practical portability, not theoretical.

There are reasonable implementations of memcpy() for which this will
not work as you seems to expect that it should.  There are also
implemenations for which it will.  The answer must be that it isn't
practically portable.

As to how it could fail, consider the use of vector registers to
transfer large chunks in parallel.

>Our latest version of Saber-C (a C environment with lots of run-time
>checking) checks for overlapping copies to the right, but purposely
>omits checks for the above cases.  I'm trying to figure out if a
>"portability mode" should be more stringent.

If the goal is to detect practical portability problems, then I'd say
that this is an obvious case to check.  But it may be difficult to do
the check on some C implementations (e.g. those on segmented
architectures), because the two pointers passed to memcpy() need not
be comparable.