Re: NUL to terminate strings; was reinventing ASCII?

On 2008-03-12, Wilhelm B. Kloke <wb@[EMAIL PROTECTED]
> wrote:
>>> In contrast, the comparison to anything
>>> else than zero needs more bytes and processor cycles.
>>
>> Not through, e.g. on x86, scasb is bounded by a number. You need a
bound
>> anyway, since relying on unbounded strings is a security risk (and in
fact
>> most string routines changed in later C revisions to add a limit to
scan)
>
> Yes, sometimes there may be a security risk, esp. in the case of library
> functions. But there are also contexts, in which it is perfectly safe
> and worth to do for performance

Note that even then it is unlikely to gain anything, since the register
comparison will generally be negiable (since pipelined) to the cache
effects of walking the string.

> There are other contexts, in which the need to touch every single byte
in
> the string by byte instructions may be detrimental to performance, and a
> length prefix is preferrable.

One doesn't exclude the other. (like Delphi, that has both length and #0
termination. Though the latter is never used by Delphi itself, only for
communicating with C)

The main problem why one can't introduce such scheme with C, as noted
earlier, is the ability to pass a poitner to a char in a string to
something
that accepts a string. Any metadata is lost that way. And the fact that
the
existing C codebase is the main reason why it exists today.

> In any case, replacing NUL by EOT or ETX doesn't help.

In general, killing terminated strings is better. But that would kill C's
only stringsup****t, which is why it survived so long in the first place.