Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Portability of some overlapping strcpy or memcpy calls
Message-ID: <9829@smoke.BRL.MIL>
Date: 9 Mar 89 16:35:28 GMT
References: <338@wjh12.harvard.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <338@wjh12.harvard.edu> kendall%saber@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.