Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mprvaxa.UUCP
Path: utzoo!watmath!clyde!floyd!vax135!cornell!uw-beaver!ubc-vision!mprvaxa!tbray
From: tbray@mprvaxa.UUCP (Tim Bray)
Newsgroups: net.lang.c
Subject: Re: structure and array and string comparisons
Message-ID: <502@mprvaxa.UUCP>
Date: Sun, 25-Mar-84 11:46:22 EST
Article-I.D.: mprvaxa.502
Posted: Sun Mar 25 11:46:22 1984
Date-Received: Tue, 27-Mar-84 00:28:36 EST
References: <253@opus.UUCP>, <365@denelcor.UUCP>
Organization: Microtel Pacific Research, Burnaby BC
Lines: 29

x <-- eat me

This response is provoked by Tim Maroney's suggestion that built-in
comparison of of arrays could be implemented in the case where the
length is not known by assuming a null element terminator.

                ************WRONG*************

The whole null-termination concept is a misfeature (yes, the costs
outweigh the benefits) and its use should be avoided in built-in
whatevers.

Other submittors have pointed out the problems which make structure/array
built-ins impractical to implement.  There is, however, one way to 
sidestep these problems:  Use a descriptor architecture.
For strings, the descriptor encodes the address and length (that's
right, no more explaining to people that you need 13 bytes to store
a 12-character string - and you can now embed null bytes in strings!)
You could also pass arrays around by descriptor and the receiving
code would not need to know in advance the size, but could determine
it unambiguously.

However, existing UNIX(tm) software is so heavily married to the
concept of null termination that it ain't gonna happen.  And look,
if wrestling with the UNIX string subroutines is the worst programming
problem you have, stop complaining... you could be composing DCB's for
IEBGENER.

Tim Bray