strcpy wars, jeez! A proposed resolution.

[David H. Wolfskill]

In article <4215 at ihlpf.ATT.COM> nevin1 at ihlpf.UUCP (00704a-Liber,N.J.) writes:
>In article <6286 at dhw68k.cts.com> I 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."

>I would not!  This would imply that a program which calls strcpy() with
>overlapping strings is 'correct', and this is simply not true.

[He then quotes the definition of "implementation-defined," as used in
the dpANS.]

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

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.

Suppose, for example, that a given implementation defines that such a
copy would be done from the beginning of the source string to its
terminating NUL, character by character.  Then (assuming suitable
definitions of the variables in question), an algorithm to clear a given
string (str1) to a given value (other than NUL) could be coded:

	*str1 = ch;
	for (c1 = str1; *++c1 != '\0'; *c1 = *(c1 -1));

or (remembering the characteristics of the implementation):

	*str1 = ch;
	strcpy(str1+1, str1)

but I think the latter is easier to comprehend.

I have used the technique -- although in assembler, rather than C -- and
am quite willing to grant that its effects are properly defined by the
characteristics of the implementation.

>If this were to change (something which I am against), all programs that
>use strcpy() would be suspect every time a new version of the compiler
>comes out (especially since many compilers use inline assembly instead of
>doing a function call for strcpy()).  This is not something which should
>depend on the implementation.

Hmmmm....  It is my understanding that if the behavior were
"implementation-defined," at least the vendor would be under an
obligation to warn you of any change in the implementation's behavior
when faced with such a construct; whether or not you chose to do
anything about it is (of course) another issue altogether.

On the other hand, if the behavior is "undefined," the vendor would be
under no obligation to indicate in any way any changes in the
implementation's behavior when faced with such a construct.  It is not
clear to me that you (or anyone else) would be well-served by such a
position.

That is really the main point of my earlier posting.

Of course, it would only be an issue for you to the extent that you need
to work with (or in spite of!) these constructs that you seem
disinclined to use anyway.  (Also, if you are sufficiently fortunate to
use a compiler that has a mode in which it flags all constructs whose
behavior is "implementation-defined," you can have that much more
warning about such concerns.)

Onward....

david
-- 
David H. Wolfskill
uucp: ...{trwrb,hplabs}!felix!dhw68k!david	InterNet: david at dhw68k.cts.com