Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: strcpy wars, jeez!  A proposed resolution.
Message-ID: <3267@haddock.ISC.COM>
Date: 31 Mar 88 18:41:36 GMT
References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <7506@brl-smoke.ARPA> <4251@hoptoad.uucp> <6286@dhw68k.cts.com> <4215@ihlpf.ATT.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 19

In article <4215@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes:
>In article <6286@dhw68k.cts.com> david@dhw68k.cts.com (David H. Wolfskill) writes:
>>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.

But it would be true, if the standard were to explicitly allow it.

>If this were to change, all programs that use strcpy() would be suspect every
>time a new version of the compiler comes out

Only those programs that use strcpy on overlapping strings.  And if the
"implementation-defined" part is properly phrased, strcpy(s,s+1) would be
guaranteed to be safe.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint