Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!hplabs!sdcrdcf!psivax!csun!aeusemrs
From: aeusemrs@csun.UUCP (Mike Stump)
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Handling -- Incompetence of run-time libraries
Message-ID: <573@csun.UUCP>
Date: Mon, 13-Apr-87 15:10:41 EST
Article-I.D.: csun.573
Posted: Mon Apr 13 15:10:41 1987
Date-Received: Sat, 18-Apr-87 23:39:56 EST
References: <15915@sun.uucp> <1987Apr1.121330.15976@sq.uucp>
Reply-To: aeusemrs@csun.UUCP (Mike Stump)
Organization: California State University, Northridge
Lines: 21
Xref: mnetor comp.arch:959 comp.lang.c:1724

In article <1987Apr1.121330.15976@sq.uucp> msb@sq.UUCP (Mark Brader) writes:
|Note also that a two-pass strcpy() should not be used in any environment
|where two processes may share data space... or in "ANSI C" jargon, where
|the source string is volatile.  If you did that, you might find that you
|have scribbled on bytes after the terminating null, or produced a
|destination string with no terminating null at all.  (The latter effect
|can of course be avoided by inserting the null separately rather than
|copying it.)
|
|Mark Brader


Well, not to pick on you, but, have you ever done ANY programming using shared
memory, succesfully, and bug free?  Tell me, how would you do something like a
strcpy in such an environment?  Please include an exact example, so that I can
show you what is wrong with it.  In orther words, why limit a two-pass strcpy
to the above?  You should just say:  ``No one should use shared memory, unless
he/she knows what they are doing''
-- 
Mike Stump, Cal State Univ, Northridge Comp Sci Department
uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!aeusemrs