Why are C and C++ all of a sudden unsafe? Did I miss something?
What is safe now? JavaScript? PyTorch?
What is safe now? JavaScript? PyTorch?
This has been known for decades, but it wasn't until 2010 that a serious attempt at writing a new system-language that was memory safe was attempted and got traction - Rust.
https://kruschecompany.com/rust-language-concise-overview/#:....
(Unless you're running it on bare metal ...)
Google it, C memory boundary issues have been a problem for security forever.
To be honest, that's a surprisingly deep question, and the answer is something I'm yet to see any developer I worked with understand. For example, did you know that SQL injection and XSS are really the same problem? And so is using template systems[0] like Mustache?
In my experience, very few people appreciate that the issue with "SQL query forming via string concatenation" isn't in the "SQL" part, but in the "string concatenation" part.
--
Really? To me it's pretty obvious that not escaping properly is the issue, and therefore the same issue applies wherever you need escaping. I don't think I've ever heard anyone say that SQL itself was the problem with SQL injection. (Although you certainly could argue that - SQL could be designed in such a way that prepared statements are mandatory and there's simply no syntax for inline values.)
The real problem is when you access memory that did allocate.
However, calloc everywhere won't save you from smashing the stack or pointer type confusion (a common source of JavaScript exploits). Very rarely is leftover data from freed memory the source of an exploit.
Have a little humility.
Memory safety means that your program is free of memory corruption bugs (such as buff overflow or under flow bugs) that could be used to retrieve data the user isn't supposed to have, or can be used to inject code/commands that then get run in the programs process. These don't get shut down by the OS because the program is interacting with its own memory.
The getting traction part is the relevance part.
1. They didn't have a big, well-known, company name with good enough reputation to attract contributors.
2. They didn't have brackets.
Success was because traction, traction was because appeal, and appeal was mostly because those two things. Nothing else was new AFAIK.
A lot of them simply assumed that some amount of "overhead," vaguely described, was acceptable to the target audience. Either tracing GC or reference counting. "but we're kinda close to C performance" was a thing that was said, but wasn't really actually true. Or rather, it was true in a different sense: as computers got faster, more application domains could deal with some overhead, and so the true domain of "low level programming languages" shrunk. And so finally, Rust came along, being able to tackle the true "last mile" for memory unsafety.
Rust even almost missed the boat on this up until as late as one year before Rust 1.0! We would have gotten closer than most if RFC 230 hadn't landed, but in retrospect this decision was absolutely pivotal for Rust to rise to the degree that it has.
Their problems was a mix of not being hieroglyph languages (too much text to type!), being much strongly typed (straitjacket programming with a famous rant post, wrongly), commercial offerings being expensive (more so against free in the box alternative), and not comming with an OS to make their use unavoidable.
Note that for all the hype, Zig is basically Modula-2 features with C syntax, to certain extent.
Early MacOS did use Pascal, though IIRC not Object Pascal.
This is a bit of a nostalgia trip for me as I owned a copy of this book way back in the 90's
https://developer.apple.com/library/archive/documentation/ma...