strcpy specifications

[Richard A. O'Keefe]

In article <4383 at ihlpf.ATT.COM>, nevin1 at 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.