strcpy wars, jeez! A proposed resolution.

[Chris Torek]

In article <4309 at ihlpf.ATT.COM> nevin1 at ihlpf.ATT.COM (00704a-Liber) writes:
>Oh, so you want the copying of two [overlapping] strings to be
>WELL-DEFINED, not implementation-defined or undefined.

Right.

>I just do not agree that you, the non-kernel applications programmer,
>should have to write code that is dependent on the *implementation*
>of a system call.

(Aside: strcpy is not a system call, it is a library routine.)

It is not dependent upon the implementation.  It is dependent upon
the specification.  The specification for strcpy was that it copies
string `src' to string `dst' such that strcpy(s+n, s) moves `s+n'
`down' n characters, while strcpy(s, s+n) `duplicates' characters
from s+1 through s+strlen(s).

That may not be what *you* read in the specification, but it *is*
what *others* read in it.  Perhaps the specification was sloppy.
You have probably seen sloppy specifications before.  The usual
answer is to tighten the spec, and if the tightened spec invalidates
a few routines, so it goes; but if, on the other hand, the tightened
spec breaks hundreds of working programs, the design team might
instead change the spec to explicitly grant those features/bugs
that everyone else interpreted it to grant.

If the semantics for strcpy() specified the action produced by copying
overlapping strings, code that copied overlapping strings would not be
dependent upon the implementation after all, would they?  The claim is
simply that the description in string(3) (the `specification') did
specify this, at least to enough people that perhaps it would be best
not to make it ill-defined.

(Begin another aside)
>... one of the reasons I like C++ ... it forces programmers to code
>without knowing the implementations of their objects/classes.  If
>the implementation of a class is changed, the rest of the code doesn't
>break.

Want to bet?  I can[*] write code that depends on all sorts of things that
may not be true in the future, even if I do not know for certain that
they are true now.  Not knowing (or caring) about the implementation
of a subclass just (1) discourages such dependencies and (2) tends to
make them more obvious, and hence easier to squash.  It does not
prevent them.

-----
*I try not to.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris