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

[Dan Cross via TUHS]

On Mon, Jan 5, 2026 at 12:28 PM 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.

Sadly, Rust turns it off for optimized ("Release") builds. Personally,
I think that's a mistake; it ought to be an _explicit_ opt-out via a
dedicated compiler option.

I used to work with a former Microsofty who had worked on Midori, and
who told me that M# (the variant of C# they used) did bounds checking
for _all_ array accesses). At one point they tried to measure the cost
of doing that, and realized it was down in the noise floor.

        - Dan C.