Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!husc6!wjh12!kendall
From: kendall@wjh12.harvard.edu (Samuel C Kendall)
Newsgroups: comp.lang.c
Subject: Portability of some overlapping strcpy or memcpy calls
Message-ID: <338@wjh12.harvard.edu>
Date: 9 Mar 89 04:24:33 GMT
Reply-To: kendall%saber@harvard.harvard.edu (Samuel C. Kendall)
Organization: Saber Software, Inc.
Lines: 33

Consider the following function call:

	memcpy(p, p + M, N)

where p is a char*, M is nonnegative, N is positive, and M < N.  This
is an overlapping copy, where the bytes are being copied to the left (M
> 0) or onto themselves (M == 0).  I am interested in finding out if
this call to memcpy, and similar calls to memccpy, strcpy, and strncpy,
are portable.

I'm interested in practical portability, not theoretical.  This call is
obviously illegal, since overlapping copies are forbidden by ANSI and
by the Unix man pages I've seen.  However, the copy succeeds in all the
implementations I've tested (Sun, Vax), and it makes sense -- you have
to go out of your way to make this kind of overlap fail.  If someone
knows of an implementation where it does fail, please let me know which
implementation it is and how it fails BY MAIL.  I'll summarize to the
net if anyone shows interest.

Details: how could this call fail to copy correctly?  The
implementations I know copy left-to-right.  An implementation that
copied right-to-left would definitely fail.  Also, an implementation
that copied in larger-than-byte units, and which couldn't handle
overlapping units, would fail for small M.  Finally, an implementation
with run-time checking for this condition would fail.

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.

	Sam Kendall	  kendall%saber@harvard.harvard.edu
	Saber Software, Inc.	      harvard!saber!kendall