Re: NUL to terminate strings; was reinventing ASCII?

James Harris wrote:
> On 6 Mar, 10:34, torb...@[EMAIL PROTECTED]
 (Torben Ægidius Mogensen)
> wrote:
>> James Harris <james.harri...@[EMAIL PROTECTED]
> writes:
> ...
>> Why would we need a null character?  I know that it in C is used as
>> end-of-string marker, but that is a horrible design decision.  If any
>> single character should mark the end of a string, it should be EOT.

It's not soo bad:
 * Comparing with a certain value is slower and requires more instructions
(or at least used to on ancient machines) than comparing with zero. Simply
loading a value was enough to detect that it's zero sometimes.
 * C did not want to require the system in question to use ASCII as
encoding, possibly because EBCDIC wasn't dead yet at that time. Requiring
a
certain value for EOT or just requiring a definition in a header would
have
worked, too, but it might have restricted the possible encodings.
 * It has some similarity with C's pointers, so that you can e.g. use both
of them in a conditional expression.

> My vague inference (which I've never had tested) is that the null
> string terminator is a consequence of C's pointer model. C is designed
> to allow a pointer to any memory object to be taken. This means C can
> depend only on knowing
> 
> 1. the address
> 2. the type
> 
> of any given object when it is operating on that object.

Further, and that is im****tant, from the type you can infer the size and
layout of the object.

However: strings are not passed with their complete type (like array of 15
characters) but instead as pointer to the first character, so the
knowledge
of the size is lost. Instead, the size must be passed along, also in order
to allow functions to handle strings of a different type. The chosen way
to
achieve that was to terminate the string, another alternative (which I
today consider better because it is safer) would have been to pass the
size
along explicitly.

> This has consequences:
> 
> 1. strings need a terminating character

In order to operate on an object, you need to know its size. Using a
signal
value to terminate the array is just one way.

> 2. arrays have no knowledge of bounds when operated upon

Yes, that's why they are typically passed along as pointer/size pair. Note
that a string is nothing else but an array of char.

> 3. header files are needed to share other info between compilation
> units

Hmmm, you mean share information about other types?

> 4. a number of functions require a count/length to be passed

Well... I wouldn't say this immediately follows from what you said but
it's
true nonetheless.

> The array issue is why C /cannot/ detect array bounds infractions. It
> cannot depend on knowing more than the addres of element zero and the
> type of the array (which includes the type of the elements).
> 
> I expect the C folks will be able to correct me. Hence I'm copying
> them this reply.
> 
> Of course, there are other ways strings can be defined, even in C,
> with the right library sup****t.

Yes, you could define them like arrays, i.e. always pass the size along.
Something like

  struct text {
    char* p;
    size_t l;
  };

...which actually makes quite readable code, I once wrote something like
this
for fun.

Uli