Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pacbell!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.lang.c
Subject: Re: strcpy
Message-ID: <4295@hoptoad.uucp>
Date: 1 Apr 88 13:27:26 GMT
References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <2148@frog.UUCP>
Organization: Grasshopper Group in San Francisco
Lines: 29

john@frog.UUCP (John Woods, Software) wrote:
> BUZZ!  No, Doug is right.  The standard (3 August 87 draft) explicitly
> states that "If copying takes place between objects that overlap, the
> behavior is undefined."  You can't *depend* on the behavior of strcpy()
> and expect to have your program be portable, QED.

If the standard was already perfect there would be no need to discuss
it.  But having an August draft say X doesn't mean that X is proven
to be true and correct, QED.

The whole discussion here is about what the standard *should* say.
Arguing that "this is right because the draft standard says it"
carries no weight at all; we knew that already and are arguing that
it is wrong.

In particular, both Chris and I have seen programs that depend on
strcpy() being able to slide a string into lower array indices without
destroying it.  We think this is a valid interpretation of the man page.
Now, some people are picking nits with the English used to document
it, which reminds me of people spending years analyzing the Bible and quoting
it to support their claims -- without once reading the original Arameic (sp?) 
to see what it really said.  In our case, we know what the original
source code said -- it copied left to right and made no bones about it.
And so far nobody has named a compiler/library/OS/environment
that *doesn't* just copy left to right.  But somebody somewhere wants
the freedom to copy all the even bytes and then all the odd bytes,
or something, and so we burn a few hundred K of comp.lang.c...
-- 
{pyramid,pacbell,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
"Don't fuck with the name space!" -- Hugh Daniel