Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!pasteur!ames!mailrus!umix!umich!mibte!gamma!ulysses!thumper!faline!bellcore!spectral!sjs
From: sjs@spectral.ctt.bellcore.com (Stan Switzer)
Newsgroups: comp.lang.c
Subject: Re: Implementation-DEPENDENT code (was:strcpy)
Message-ID: <6743@bellcore.bellcore.com>
Date: 15 Apr 88 14:03:44 GMT
References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <6670@bellcore.bellcore.com> <258@sdrc.UUCP>
Sender: news@bellcore.bellcore.com
Reply-To: sjs@spectral.UUCP (Stan Switzer)
Organization: Computer Technology Transfer, Bellcore
Lines: 28

I wrote:
> > I think a few observations can be made about this "tempest-in-a-teapot"
> > 
> >   1) Some (most, possibly all) implementations DO implement strcpy
> >      left-to-right.   (prior-art)

In article <258@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes:
> Nope.  Practically all VAX implementations use the VAX MOVC3 instruction which
> moves EITHER left-to-right OR right-to-left, whichever is needed to get the
> "right" answer (an intact copy).

You are, of course, correct.  I noticed this after I sent it.  What I meant
is that all known implementations implement strcpy(s,d) s.t. when s and d
overlap and s < d, the copy is non-destructive.  This is the essential point.

My point still stands that
  1) in all known implementations it "does the right thing"
  2) changing it can break existing working code (granted that it is based
     on a tacit though universally true assumption).
  3) there is no known reason why on any implementation it could be
     inefficient to require this semantics (and considerable reason to
     doubt that it ever could be more inefficient, given that you would have
     to count 'd' first anyway).

So, where is the justification for not requiring this overlapped copy
to work?

Stan Switzer