Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!ames!ucbcad!ucbvax!decvax!decwrl!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.arch
Subject: Re: String Processing Instruction
Message-ID: <15829@sun.uucp>
Date: Mon, 30-Mar-87 03:38:21 EST
Article-I.D.: sun.15829
Posted: Mon Mar 30 03:38:21 1987
Date-Received: Tue, 31-Mar-87 05:52:19 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <909@spar.SPAR.SLB.COM> <236@winchester.mips.UUCP> <182@homxb.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Distribution: na
Organization: Sun Microsystems, Mountain View
Lines: 18

>If the C convention for strings had been length oriented, I suspect that
>Dhrystone would come out with a better approximation of reality.  This
>would be due to the heavier usage of mem*-like routines for moving and
>comparing the strings.

Why would people use mem*-like routines for manipulating counted
strings, but not use str*-like routines for manipulating
null-terminated ones?  The only reason I can think of is that since
finding the length/end of a string is a constant-time operation with
counted strings, but is linear in the length of the string with
null-terminated strings, people would be less tempted to write their
own string manipulation code that found the end of a string as a side
effect of the processing.  Is this what you had in mind?

I'd be interested to know how much string processing is, in fact,
done by *ad hoc* code because it didn't quite match the string
routines available on the system?  "strtok" and company weren't in
V7, so people would usually have done their own string-chopping.