[TUHS] Buffer overflow found/fixed in v4 tape ;)

[Luther Johnson via TUHS]

I think in the beginning it just wasn't considered, that we had to 
protect against programs intentionally doing harm. Who would do that ? 
But now we know.

On 01/05/2026 10:46 AM, Bakul Shah via TUHS wrote:
> On Jan 5, 2026, at 9:27 AM, Clem Cole via TUHS <tuhs at tuhs.org> wrote:
>> On Mon, Jan 5, 2026 at 12:08 PM Paul Winalski via TUHS <tuhs at tuhs.org>
>> wrote:
>>
>>> The problem with that philosophy is that a buffer overflow doesn't
>>> necessarily lead to a program crash.  A program crash is the lucky
>>> outcome.  If you're unlucky you will silently get the wrong answer, or
>>> other misbehavior.
>>>
>> Right - which is why it took something catastrophic like the Morris Worm
>> and shortly thereafter, the infamous smash the stack paper: (
>> https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf) for
>> people to wake up to the fact that it really was an issue for many
>> programs.
>>
>> I recall that some of the language folks (particularly those heavily
>> involved in the Pascal *vs.* C war) like to say things like: *"See, the
>> compiler should have general bounds-checking code."  *I can't say I agreed
>> on the general topic (there were too many things Pascal got wrong), but
>> note that today both Go and Rust provide automatic bounds checking for all
>> array and slice accesses at runtime.
> Actually Pascal got a lot of things right. Coming from being intimately
> familiar with Pascal and its orig. compiler, I disliked these things in C:
> 1. poor array support, no multi-dim arrays
> 2. C's union type vs Pascal's variant records
> 3. no subrange type
> 4. C's poor type system
> 5. C's enum type which are essentiall integers vs Pascal's strict enumeration type
> 6. No nested functions.
>
> [Of course, there were many things to like in C as well.]
>
> Granted, it was not as clean and orthogonal as Algol68 (whose popularity
> suffered from surface issues such as use of vW grammar od choice of keywords
> etc.).
>
> Also note that pretty much all non-C compilers pre-1988 generate code to
> do bounds check -- at least as an option but more often the option was to
> turn *off* bounds check!
>
> Now that we are aware of the danger of no bounds check, we seem to have gone
> to other extreme of using complicated languages like Rust....