Re: NUL to terminate strings; was reinventing ASCII?

On 10 Mar, 12:13, Ben Bacarisse <ben.use...@[EMAIL PROTECTED]
> wrote:
> James Harris <james.harri...@[EMAIL PROTECTED]
> writes:
> > On 8 Mar, 17:22, Ben Bacarisse <ben.use...@[EMAIL PROTECTED]
> wrote:
> > ...
> >> So they need a terminating character unless they are defined some
> >> other way?  Surely the question was why were they not defined in one
> >> of these other ways?
>
> > Yes, I mean that to allow C strings to be defined as they are by a
> > single pointer requires there to be a terminating character of some
> > sort.
>
> But this is not true -- at least not literally true.  In BCPL strings
> were represented by a single pointer, but that pointer was to a
> length.  I am sure you are not unaware of this kind of representation,
> I just think you are over-cooking the argument to come up with
> "requires there to be a terminating character".  I see no such
> requirement -- it could have been different.
>
> I suspect I am reading more into your statement than you intended.

I see your point and appreciate being made to think this through more
clearly. I suppose the bit missing from what I said above is that the
C concept of a string being an array (of char) allows nowhere for a
length prefix. If it is an array of char then all elements should be
of type char. I suppose the libraries could just ignore this
requirement (could they?) but then would have to agree on how many
bytes made up the length and in what order they existed. Hmm....

I was comparing this with the definition of a string as a tuple of
(address, length) where BOTH elements are passed as parameters - i.e.
a single reference to the string embeds both parameters or expects
both as arguments. As far as I can see tuples of this sort cannot be
used in C.

The remaining option (I think there are just these three primary
options for strings but would welcome correction) is to store
(address, length) separately and point to it. It's not as flexible as
the tuple option above and not as simple as C's string handling. I
guess it could have been used but maybe the following comment from the
paper you referred to above helps explain why C went the way it did:

"
Problems became evident when I tried to extend the type notation,
especially to add structured (record) types. Structures, it seemed,
should map in an intuitive way onto memory in the machine, but in a
structure containing an array, there was no good place to stash the
pointer containing the base of the array, nor any convenient way to
arrange that it be initialized. For example, the directory entries of
early Unix systems might be described in C as

    struct {
    	int	inumber;
    	char	name[14];
    };

I wanted the structure not merely to characterize an abstract object
but also to describe a collection of bits that might be read from a
directory. Where could the compiler hide the pointer to name that the
semantics demanded? Even if structures were thought of more
abstractly, and the space for pointers could be hidden somehow, how
could I handle the technical problem of properly initializing these
pointers when allocating a complicated object, perhaps one that
specified structures containing arrays containing structures to
arbitrary depth?

The solution constituted the crucial jump in the evolutionary chain
between typeless BCPL and typed C. It eliminated the materialization
of the pointer in storage, and instead caused the creation of the
pointer when the array name is mentioned in an expression. The rule,
which survives in today's C, is that values of array type are
converted, when they appear in expressions, into pointers to the first
of the objects making up the array.
"