[Info-vax] Whither VMS?

[glen herrmannsfeldt]

Bob Eager <rde42 at spamcop.net> wrote:
< On Thu, 01 Oct 2009 09:07:02 -0500, Bob Koehler wrote:
<> In article <7ij0ueF30a3ujU4 at mid.individual.net>, Bob Eager
<> <rde42 at spamcop.net> writes:
 
<>    Which makes you wonder why the inventors of C settled on such a
<>    design in a day when CPUs were so much slower.  If I had a system
<>    slower than a PDP-11/70, I'd have wanted it to spend it's time doing
<>    better things.
 
< I never saw that that, in particular, caused any kind of performance 
< problem. The libraries that used it were few - it's not often that you 
< need to know the length of a string; more often you need to know when 
< you've reached the end, and that is equally well served by a count or a 
< terminator.

I have.  I have seen strcat() called inside a loop for building
up a string while reading it in one line at a time.  The resulting
algorithm is O(n**2).  (O(pow(n,2)) for C programmers.)  It was
fast enough in testing, but in production the strings were millions
of characters long and most of the time was spent in that loop.
 
< However, they didn't want a real limit on the lengths of strings. If 
< they'd used a length prefix (as the predecessor to C did) they'd have had 
< to make it two bytes, minimum. That would have used an extra byte per 
< string, a waste of an even more valuable resource.

One result of null termination is the easy buffer overflow of
many programs today that don't properly check lengths.  Length
at the beginning doesn't work so well if you want pointers to
other than the beginning of a string.  The other way is with
a structure containing a length and pointer, pretty much what
Java does with String.
 
< CPU time is 'extensible'; you can wait a little longer. Memory is not; 
< lack of it is a showstopper (overlays aside).

Assuming that the program finishes before you need the result.

-- glen