Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utfyzx!sq!msb
From: msb@sq.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Handling -- Incompetence of run-time libraries
Message-ID: <1987Apr1.121330.15976@sq.uucp>
Date: Wed, 1-Apr-87 12:13:30 EST
Article-I.D.: sq.1987Apr1.121330.15976
Posted: Wed Apr  1 12:13:30 1987
Date-Received: Sat, 4-Apr-87 06:26:52 EST
References: <15915@sun.uucp>
Reply-To: msb@sq.UUCP (Mark Brader)
Organization: SoftQuad Inc., Toronto
Lines: 20
Xref: utgpu comp.arch:742 comp.lang.c:1415
Checksum: 37718
Summary: two-pass strcpy() unsafe with shared memory

> Note that the library "strcpy" uses "locc" to find the length of the
> source string and then does a "movc3" to copy it.  This requires two
> passes over the source string.  Whether the whizzo VAX string
> twiddling instructions are a win or not depends on how long the
> strings are.

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

When I had to do some work on VMS a couple of years ago, we found that
the VMS implementation of strcpy() was considerably slower than locc-movc3
for the string lengths we were working on, and we decided that this was
the reason.

Mark Brader