GCC 14 Boasts Nice ASCII Art For Visualizing Buffer Overflows

[kpedersen]

It's not the only language in town able to do that. Java has had protection against buffer overflows since 1995. Python, PHP, C# etc. all handle those gracefully. You'd need a dependently typed language to prevent those at compile time. But there are those languages as well.

Indeed and C++'s std::vector<T>::at and std::array<T>::at.

Runtime bounds checking was solved in the 90s (basically once computers got fast enough to waste time on safety) and that's the most important. Otherwise a linter is generally adequate for static / compile time arrays.

[pong]

Given how far off April Fools Day was (many many hours as of this post) I guess your clocks are not sync'd to NTP?

CVE-2024-0403 -- chained zero-day exploits in NTP off-by-1 handling of leap year + days-in-month-x calculations extend April fools 2024 until 03-April. That is all.

[pong]

FWIW I considered implementing a new warning: -Wits-2024-why-are-you-still-using-a-memory-unsafe-language for April 1st, but thought better of it :-P

Thank you for thinking better of it. That would have been in extremely poor taste, and could have actually been harmful if
you accidentally gave someone the mistaken impression that you were kidding and that it isn't actually a very good idea!

[pong]

Plenty of us do, myself included. Rust is a really good tool for some things and I'm quite content to use it or those things. I don't run around beating a drum about it, though.

But I absolutely will hammer that drum on the memory safety talking point when someone who is rather green to the IT world argues that we need to stay with C. I've spent too many late nights patching memory vulnerabilities to have any patience for such nonsense.

Agreed.

It actually wouldn't be so bad in almost every case if people DIDN'T use memory safe languages but DID implement code / documentation according to principles like SRP, DBC, DRY, validating contractual pre/post conditions & invariants, etc.

So it'd be cognitively harder to even WRITE code (in an unsafe language) that violated bounds since that'd be basically the entire point of the ~4 line C function to
ensure that bounds weren't violated and therefore the contract could be met safely and the requested operation could succeed. Absent a mound of spaghetti code that much should be possible to code logically ~100% correctly. And even if one didn't the unit test and contract validation / assertions should catch it before it does something silently worse.

It's really the fact that people are too lazy to:
A: Design.
B: Document.
C: Implement tests.
D: Test.
E: Validate arguments & intermediaries.
F: Keep their functions minimal and avoid embedding everything in an opaque wall of spaghetti code.

.. that produces catastrophe.


Of course even with care it is still unfortunately uncommon / difficult to get it wholly right:

https://blog.research.google/2006/06/extra-extra-read-all-about-it-nearly.html

[reba]

Looks great and surely improves ease of understandability.

Is it available as a crate so many other projects can benefit from this work?

[Vistaus]

Given how far off April Fools Day was (many many hours as of this post) I guess your clocks are not sync'd to NTP?

The Fedora proposal to switch to KDE was officially announced on April 2, but people still called it an April Fools joke.

[yoshi314]

that is why i hate apr 1st with a passion. nothing can be taken seriously.

[dmalcolm]

that is why i hate apr 1st with a passion. nothing can be taken seriously.

Totally agree; I had concerns about posting the article when I did, but wanted to get it out before GCC 14.1

I made sure to put in lots of links to Compiler Explorer, so someone with reasonable skepticism can try the features out and verify they actually work. I promise there are no rickrolls in the URLs

[NSLW]

Visually it looks cool.

[murlakatamenka]

I shill Rust as much as the next guy, but we have got to stop beating the "memory safety" drum. That ain't special

The second thing we gotta stop doing is never shutting up about Rust

I'd say my message is more about paradigm shift and solving the systematic issue with a systematic approach. And without runtime penalties.