[billyhoffman]

I guess that's what I'm sad about.

Manual memory management feels like how early automobiles allowed you to adjust the fuel/air mixture by turning a knob: Why are you making me deal with this?

There are documents from the US Airforce's computer security group in the mid 1970s talking about buffer overflows. How years and many units of significant digits of precision do we need on the concept that human are fucking terrible at managing their own memory.

Yes [insert argument about garbage collection stalls] and yes [insert argument about guaranteed response times], but for the vast majority of programming projects those simply don't apply.

The fact that is 2019 and we are still dealing with this is so depressing.

[ashurov]

"There are documents from the US Airforce's computer security group in the mid 1970s talking about buffer overflows.": could you point me to this/provide more information?

[schoen]

Presumably this is about Karger and Schell (1974). A 2002 reprint with nicer formatting is at

https://www.acsac.org/2002/papers/classic-multics-orig.pdf

It's sometimes said that they discovered or anticipated a lot of things that would preoccupy us over the next decades. I was personally familiar with them because David Wheeler mentioned that they anticipated the "trusting trust" issue with a compromised compiler.

Some of their terminology is different from current terminology, but there is, for example, a discussion of tampering with the stack in order to alter variables or control flow. I'm not sure whether the buffer overflow mechanism is discussed because the part that I think I understand is a different means of stack manipulation, specific to this environment.

An obituary for Paul Karger:

https://www.ieee-security.org/Cipher/Newsbriefs/2010/karger....