strcpy wars, jeez! A proposed resolution.

[00704a-Liber]

In article <10962 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>In article <4309 at ihlpf.ATT.COM> nevin1 at ihlpf.ATT.COM (00704a-Liber) writes:
>>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.

>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).

It still IS dependent on the implmentation; you just want ANSI to put the
implementation in the specification.

You are not defining *what* the function does (ie, you are not making an
abstract *description* of the function); you are defining *how* the
function does a strcpy (ie, how it is suppose to be *implemented*).  If I
give you (for a small licensing fee :-)) all the lines of assembler for
Unix and call that the specification of Unix, you will never be able to say
that their is a bug in Unix (after all, it's doing everything exactly as
written in the assembler code).

There is no 'such that' part in the specification of strcpy().  Strcpy(),
according to the man page, INCLUDING THE WARNING (something a heck of a lot
of posters neglected to read), says:

"Strcpy copies string s2 to s1, stopping after the null character has been
copied. [...] [Strcpy] returns s1.
[...]
WARNING
[...]
Character movement is performed differently in different implementations.
Thus overlapping moves may yield surprises."

>That may not be what *you* read in the specification, but it *is*
>what *others* read in it.

You are saying that overlapping does *not* yield surprises, which is a direct
contradiction with the specification.

>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.

If I specify the source code for the compiler, then nothing about the
language can be ill-defined.  But, as you have already shown, not
everybody bothers to read the entire specification, anyway.


>(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.

Agreed.  I should not of said that it 'forces' programmers to code well, but
that it makes it easier to code well.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah