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

[Dan Cross via TUHS]

[Note: TUHS to Bcc: and Cc: to COFF. This has nothing to do with Unix]

On Mon, Jan 5, 2026 at 2:16 PM Steffen Nurpmeso via TUHS <tuhs at tuhs.org> wrote:
> [snip]
> ..and fact is that any language i know supports bound-checked
> array accesses.  You only have to code it.  And have the
> discipline to use that interface, and that interface alone.
> This argument extends to more things.

Note: you took a note about what Rust does with bounds checking, and
turned it into a rant about how you don't see value in memory safety.

My experience is that people tend to react to languages things like
Rust in one of three ways: 1) they are unabashed fan boys who suggest
that anyone not programming in Rust is an idiot, 2) they acknowledge
the strengths and potential benefits and can appreciate the positives
of programming at a higher level of abstraction, while still pointing
out flaws and being cautious about potential pitfalls (tooling,
complexity, training, whatever; you name it), or 3) they assert that
there's nothing useful here and anyone who's programming in Rust is an
idiot desperately looking for tools to cover up their incompetence,
and that the real solution is to just be a Better Programmer.  Of
course, Rust is just an example here; these broad categories of
reactions are true of any number of technologies.

Of the three, I've found that those falling into the first camp
basically never write software but spend an awful lot of time writing
blogs or commenting on hacker news.  Those in the third category are
similar, though they've likely _stopped_ writing lots of code.  Those
in the second category, who can appreciate nuance and weigh tradeoffs
objectively, tend to be the best engineers.

My own take here is your argument defeats itself in the above
paragraph: 60 years of professional programming history have shown
that those "only have to code it" and "having the discipline" things
don't hold up at scale.  Sure, we can all belly up to the bar and
complain about how the kids these days just don't have the skill,
intelligence, or intestinal fortitude to write competent C code, but
professionals understand that tools evolve and defense-in-depth and
automation are good when it comes to writing reliable software.

If you think it's just a matter of discipline, well...good luck with
that. History and available evidence disagree.

> In early September 2024 there was a very long thread on some
> FreeBSD list where a long time contributor and kernel hacker
> jumped into the at that time "hot" (there was that Linux
> filesystem discussion thing where a Rust promoter stepped down
> not back after claiming that ~"blocking Rust" is "non-technical
> nonsense" (Google says for "linux rust non-techincal nonsense").
> And he said
>
>  |> In fact, of all the C bug fixes that I've been involved with (as
>  |> either author or reviewer) since May, about three quarters could've
>  |> been avoided just by using a better language.
>  |...
>  |> To summarize, here's the list of this week's security advisories, and
>  |> also some other recent C bug fixes of my own involvement
>
> That really interested me, and i looked over them [1], likely not
> longer than a minute code-looking for each one (claiming t"he ones
> from OpenSSL and ctld are more complex" instead of looking more
> deeply), and i ended up saying
>
>   Examples.  I find the absolute opposite after checking four.

I don't see how this can be claimed to be the "opposite."  It may be
that you aren't convinced that Rust has any advantages over C for the
examples given that you looked at, but that is very different than
claiming that Rust makes the code _worse_ and unsafe (which is what
the opposite claim implies).

> Later in the thread one developer of a patch i did not look
> further into because of complexity stated his was ~"not a C error"
> either.  So that is that.
>
> And then, how could any language help when, as i say in [1],
> "a byte buffer of reality matches a structure of a language
> abstraction".  More than C?
> And things often seen in C, beyond that struct{x;y;char flex[];},
> where a larger buffer is allocated to store some structure at
> the bottom and a buffer thereafter, in one hot memory chunk.
> You can create an interface that accesses memory within "flex"
> safely, even then.
> And then you can use a string object that knows its length.
> And all that -- you all know that, better than i do.
>
> In the non-mellow sphere of programmers lots of sledgehammerheads
> bang into this "memory safe" notch, as if they were the "king of
> the bongo .. bong!".
>
> Whereas i think it is beneficial to create a wider context so that
> at least in certain forums different realities can be heard.
> Not that it all ends up with AI rewriting any C or C++ code in
> Rust, without any little human programmer getting paid for
> anything of that rewrite, which does not fix just one logic error.
>
>   [1] https://marc.info/?l=freebsd-hackers&m=172557660704363&w=2
>
> Array bound checking, i mean, come on.  Cheech and Chong are
> beaners without that.

That's a racial slur. Not cool.

        - Dan C.