[TUHS] Buffer overflow found/fixed in v4 tape ;)
Bakul Shah via TUHS
tuhs at tuhs.org
Tue Jan 6 03:46:50 AEST 2026
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....
More information about the TUHS
mailing list