Comment by sirwhinesalot

2 days ago

I don't particularly care about Rust vs Fil-C shit flinging, I don't even see them as competing since they have effectively near opposite tradeoffs.

You could even use Rust alongside Fil-C to ensure the unsafe blocks are safe. It would even be interesting to turn off some of Fil-C's expensive protections in the safe parts of the Rust code, making an average-of-both-worlds sort of solution.

What I do care about are C and C++, these two absolute garbage languages (though I do have a lot of love for C, you can both love and hate something).

Tools like Fil-C, hardened mallocs like SlimGuard, and other "make C safe" solutions all sacrifice absurd amounts of performance because these two moronic languages refuse to have a proper slice/span type.

Use-after-free and double-free are serious problems but they're a spec of dust compared to missing bounds-checks. The low-hanging fruit is right there for the picking but everyone is worried about how to reach the fruits at the top.

C++ only now in C++26 is finally adding bounds checks to the [] operator on std::span and (hilariously) is also finally adding the now mostly redundant .at() method which should have been there from day one.

Clang added -fbounds-safety which is a feature that should have existed for a long time and serves as a decent stop-gap to a proper slice type. But of course, since it's not standardized, most people won't use it.

What these two languages have taught us is that if you want to produce utter garbage you should make it an ISO standard.

Me, personally, I find this whole discussion on memory safety amusing. Missing bounds checks are by far the biggest source of vulnerabilities and they're a problem in exactly 2 languages and those 2 languages have outright refused to do anything about it for decades.

But hey, even in memory safe languages you have frameworks like log4j that had remote code execution from a format string as a feature. Is the problem memory safety specifically, or this utter cavalier attitude towards security?

I'm not even suggesting something dumb like "you just gotta get good at C and then you won't have any vulnerabilities". Humans are fallible, which is why we delegate what we can to machines. I'm just pointing out the utter lack of care. People just don't care.

At least do the bare minimum of effort like, I don't know, not make remote code execution a feature tied to format strings. Or provide a slice type in your language and string manipulation functions in your standard library that make use of it, preferably 20 years ago.

C++ has had bounds checking in standard library for ages, and on compiler specific frameworks like MFC and OWL, however plenty of devs apparently never read the compiler manuals on how to improve safety and related compiler settings.

It is also relatively strange that many devs use the lacks of standardisation as an excuse to not adopt safety features in C and C++, while at the same time rush out to adopt cool toys that are specific to a single compiler.

  • For std::string and std::vector yes, but not for std::span (until C++26) for reasons I cannot understand.

    • That is standardese, you get them all bounds checked by using specific compiler flags.

      Here is for VC++

      https://github.com/microsoft/STL/blob/2a62bf7b4079f0a3e33ec8...

      You just have to define the proper iterator level for enabling bounds checking.

      Other compilers have similar approaches.

      I chose VC++ on purpose, because it is what I know better, and is famously trailing behind C++26 features.

      Then there are the Tclass, Cclass, Qclass, from all those C++ frameworks pre C++98.

      However plenty devs seem allergic to learn about how to use their compilers.

      1 reply →

> You could even use Rust alongside Fil-C to ensure the unsafe blocks are safe.

Isn't this what MIRI already does?

  • Partially yes. Fil-C goes further in creating an entire ecosystem of Fil-C compiled "legacy" libraries, meaning all the unsafe FFI your Rust code does into C is also safe, and even many linux syscalls.

    Miri is meant as more of a sanitizer type tool that you use during development to catch bugs. Fil-C is a platform you compile your entire Linux distro with for use in production.

    • I thought you meant to use Fil-C as a kind of sanitizer too.

      I don't see a point in running Rust code in Fil-C. Due to the way Fil-C works it won't be enough to check the `unsafe` statements, so you'll pay the performance tax on safe code too (onto which you already paid the borrow checker tax!)