[clug] [OT] Null-terminated strings: expensive mistake or not

[Robert Edwards]

On 04/08/11 13:12, Hugh Fisher wrote:
> steve jenkin wrote:
>> A friend sent me this link making a case that null-terminated strings
>> were "The Most Expensive One-byte Mistake".
> ...
>>
>> There are a bunch of C and other coders on the list.
>> Thought you might have interesting opinions on this.
>>
>
> Blame for buffer overruns can be pushed back to IBM and their
> decision with the 360 to go for a common address space with
> code and data intermingled rather than segmented and typed
> memory like the Burroughs 5/6XXX series. On a B6700 a string
> would just wipe out your local variables and then crash with
> the equivalent of SEGV instead of overwriting the return
> address.

I don't think there is any imperative reason to put the local
variables into the same stack as return addresses and saved registers.
It is just a compiler design decision. Certainly on some small
microcontrollers, there is no way to put local variables into
the return address stack, and so the compiler needs to maintain
a separate stack for local variables elsewhere in memory. We could
have the same with i386/x64/arm/sparc etc., if we wanted to modify
gcc to produce code to do that. Doing so would slightly increase
overheads, but largely avoid the whole problem of buffer overruns
corrupting the return address on the stack.

>
> Don't know how it compares with null terminated strings, but
> IBM also made a one byte mistake with the 360. Pointers were
> 32 bit, but the hardware only used 24 bits for addressing.
> IBM forgot to check the upper 8 bits, so programmers stuffed
> useful flags into pointers. When mainframe memory finally
> started going above 16M in the 1980s (IIRC), said programs
> started crashing.
>
> And just to prove the "those who ignore history are doomed
> to repeat it" thing, Motorola made exactly the same mistake
> with the 68000, causing Apple/Sun/etc much grief in the
> 1990s.

I'm not sure how this is Motorola's mistake. They can't help how
the compiler writers for Apple and Sun may have used the extra
bits of memory that existed in the upper bits of all pointers that
weren't using all 32-bits.

Presumably the same issue could recur now that we have 64-bit
addresses but not so many machines with 16 exabytes of memory and
so some (many) unused bits to play with in each pointer.

>
> cheers,
> Hugh

Cheers,

Bob Edwards.