strcpy wars, jeez! A proposed resolution.

[00704a-Liber]

In article <6476 at dhw68k.cts.com> david at dhw68k.cts.com (David H. Wolfskill) writes:
>In article <4215 at ihlpf.ATT.COM> nevin1 at ihlpf.UUCP (00704a-Liber,N.J.) writes:
>>In article <6286 at dhw68k.cts.com> David Wolfskill wrote:
>>>The current dpANS also specifies "If copying takes place between objects
>>>that overlap, the behavior is undefined."  I would feel rather more
>>>comfortable with changing that to read "... implementation defined."
>
>>If you have overlapping strings you have incorrect data.
>
>Well, thank you for your opinion; however, I respectfully disagree.
>Given an order in which the copying shall be done, the operation of
>copying data from one string to another (when the two strings have a
>known degree of overlap) can be a well-defined one.

Oh, so you want the copying of two strings to be WELL-DEFINED, not
implementation-defined or undefined.  Why did you beat around the bush for
so long??  I do agree that if you know the algorithm, all the side effects
are well-defined.  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.  This only leads to nightmares for code
maintenance people (which is part of my job).

For example:  some of the people right now who are arguing for strcpy() to
be *defined* as left-to-right string copy are bringing up the point that
code currently being used is dependent on this implementation of strcpy().
They are claiming that it is hard to maintain since it is
implementation-dependent.  We should be going away from code like this, not
towards it.  This is one of the reasons I like C++, because 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.

>It is quite possible -- and to me, reasonable -- to define an algorithm
>in such a way that it uses the implementation-defined behavior of such
>an operation.

You are right in one sense:  it is quite possible to define an algorithm in
such a way that it uses the *side effects* (aka, implementation-defined
behavior) of such an operation.  If you are writing code like this then you
are becoming very dependent on your particular version/implementation of C.

Good luck in three years, when your implementation is outdated!
-- 
 _ __			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