Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: strcpy specifications
Message-ID: <871@cresswell.quintus.UUCP>
Date: 13 Apr 88 00:42:26 GMT
References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <4383@ihlpf.ATT.COM>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 36

In article <4383@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes:
> As my man page states.
> >1.  copies string `src' to `dst'; if src and dst overlap, the result
> >    is implementation-defined.

I find that the 2nd edition of the System V Interface Definition says that
	Character movement is performed differently in different
	implementations.  Thus overlapping moves may yield surprises.

Since I generally take the SVID to be the official definition of things,
it follows that I was wrong to rely on strcpy(s, s+1) and should now use
my own C code in such cases.  Sigh.  It would be nice to have a definition
of what precisely IS an "overlapping move":  I have encountered machines
where the critical area was the range of _words_ including a sequence, not
the bytes alone.

Nevin Liber objected to Chris Torek's attempt to define strcpy() by
exhibiting C code for it.  It may be naive of me, but since the rest of
the standard is supposed to define the constructs Chris Torek used,
giving a definition by means of C code seems to me to be the ideal way
of defining such operations.  I have no reason to expect the dpANS
drafters to be any better at writing English definitions of things than
Chris Torek is at writing C code, and you can at least _test_ the C code
to see if it does what you intended.  From a user's point of view, having
something defined so clearly and unambiguously seems like a good idea.

C code is appropriate for defining some things (notably the "string"
operations) and not appropriate for others (notably the floating-point
library functions).  I think there are two reasons for this:
(a) The "string" operations only need primitive operations which the
    rest of the standard is supposed to define thoroughly, but cos() and
    so on depend on floating-point arithmetic which the standard leaves
    rather vague and (necessarily) rather implementation-dependent.
(b) The "string" operations belong to C, so the C community can define
    them however they please, but cos() and so on already have other
    definitions, so can't be bent to suit C's convenience.