In article <7xmxuffpxp....@ruckus.brouhaha.com>, Paul Rubin <no.em...@nospam.invalid> wrote:
> Gregory Ewing <greg.ew...@canterbury.ac.nz> writes: > > I don't think it was as stupid as that back when C was > > designed. Every byte of memory was precious in those days, > > and if you had, say, 10 bytes allocated for a string, you > > wanted to be able to use all 10 of them for useful data. > > No I don't think so. Traditional C strings simply didn't carry length > info except for the nul byte at the end. Most string functions expected > the nul to be there. The nul byte convention (instead of having a > header word with a length) arguably saved some space both by eliminating > a multi-byte header and by allowing trailing substrings to be > represented as pointers into a larger string. In retrospect it seems > like a big error. Null-terminated strings predate C. Various assembler languages had ASCIIZ (or similar) directives long before that. The nice thing about null-terminated strings is how portable they have been over various word lengths. Life would have been truly inconvenient if K&R had picked, say, a 16-bit length field, and then we needed to bump that up to 32 bits in the 80's, and again to 64 bits in the 90's. -- http://mail.python.org/mailman/listinfo/python-list
