Path: utzoo!mnetor!uunet!husc6!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: strcpy
Message-ID: <18516@think.UUCP>
Date: 25 Mar 88 01:33:24 GMT
References: <12622@brl-adm.ARPA>
Sender: usenet@think.UUCP
Reply-To: barmar@fafnir.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 32

In article <12622@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes:
>Of course, with C's string representation, copying from beginning to
>end is more efficient than finding the end of the source string and
>copying backward.

Depends on the hardware.  If a machine has a fast instruction that
does a search for a byte and a fast block move instruction, it would
probably be best for strcpy to be written

	memcpy (dest, src, strpos (src, '\0') + 1);

(assuming that memcpy and strpos are inlined into the appropriate
instructions, otherwise strcpy should be written in assembler to take
advantage of the hardware).

Of course, if you have hardware that knows how to do a block transfer
until a particular character is reached, that would even be better.
Honeywell's Multics mainframes have such a thing in their Extended
Instruction Set.  (It's actually more general than this, because you
give it a table where each byte corresponds to a particular character
value -- it stops when it encounters a character whose table entry is
nonzero and returns the pointer to that character in a register and
the table entry value.  It can therefore implement the strspn family
of functions, and is especially useful for lexical analyzers because
the character table can be used to implement a state transition table
-- I can envision a three-instruction FSM loop.)

Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar