Announcement

Collapse
No announcement yet.

GCC 14 Boasts Nice ASCII Art For Visualizing Buffer Overflows

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • murlakatamenka
    replied
    Originally posted by bacteriamanicure View Post
    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.

    Leave a comment:


  • NSLW
    replied
    Visually it looks cool.

    Leave a comment:


  • dmalcolm
    replied
    Originally posted by yoshi314 View Post
    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

    Leave a comment:


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

    Leave a comment:


  • Vistaus
    replied
    Originally posted by NotMine999 View Post

    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.

    Leave a comment:


  • reba
    replied
    Looks great and surely improves ease of understandability.

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

    Leave a comment:


  • pong
    replied
    Originally posted by wswartzendruber View Post
    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:

    Posted by Joshua Bloch, Software EngineerI remember vividly Jon Bentley's first Algorithms lecture at CMU, where he asked all of us incoming Ph.D. ...


    Leave a comment:


  • pong
    replied
    Originally posted by dmalcolm View Post

    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!

    Leave a comment:


  • pong
    replied
    Originally posted by NotMine999 View Post

    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.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by caligula View Post

    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.

    Leave a comment:

Working...
X