strcpy wars, jeez! A proposed resolution.

[David H. Wolfskill]

[I had suggested that strcpy() on overlapping objects ought to be
"implementation-defined," rather than "undefined," behavior.  Liber
then wrote "If you have overlapping strings you have incorrect data."
I made the mistake of suggesting that the operation need not involve
incorrect data at all, but could be well-defined.  The act of making
that suggestion was a mistake, in that it had little (if anything) to
do with the discussion at hand.]

In article <4309 at ihlpf.ATT.COM> nevin1 at ihlpf.UUCP (00704a-Liber,N.J.) writes:
>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??

No.  I am *not* asking that it be (necessarily) well-defined.  I am
suggesting that the Standard ought to require a conforming
implementation to *document* that implementation's behavior, so that
someone reading the implementation's documentation of strcpy() can make
a determination about the suitability of the implementation for the
purposes the individual has in mind -- and so the implementor will also
be required to inform the users of the implementation if that
implementation changes.

It is quite possible to have such an implementation that documents that
its behavior, when faced with such a construct, is that "Unpredictable
results may occur."  Another (competing) implementation may make a
guarantee about the results of such an operation.  It is even possible
that (for the purpos(es) at hand), it makes no difference; at this
point, the individuals responsible for acquiring a given implementation
have a point of comparison -- we now have a "quality of implementation"
issue.

I sent my comments in to X3J11; we wouldn't want the committee to suffer
from a lack of opinion....  :-)

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