Hacker News Reader

Comment by denim_chicken | Hacker News Reader

Neither is Rust, which comes with a huge RTS that itself likely full of such bugs. The library and the compiler too may have bugs that compromise the "guaranteed" memory safety of a libc written in Rust.

There is no silver bullet here. If one takes into account all the sources of bugs, C may very well be the best choice given its maturity and its ecosystem. Our best bet is likely to put more resources towards glibc development and especially fuzz testing. I bet there are only 1-2 developers who work on glibc full-time.

View on HN

Rust does not really have an RTS per se. libstd is just a standard library.

Also, even if rustc has soundness bugs, you won't find them if you don't look for them, and even then, just trying to make your program fit the types will prevent most bugs.

By the way, glibc's code is too horrible to be read - musl is a more modern alternative.

> Rust does not really have an RTS per se. libstd is just a standard library.

And if you don't want to use the standard library, you just say #![no_std] https://doc.rust-lang.org/stable/book/using-rust-without-the...

Has there been any work on a safe C? Not a C-ish language that is safe, but an actual implementation of the C language itself.

The C standard doesn't require the compiler to check the validity of array indexing and pointer dereferences and such, but it also doesn't require the compiler not to. Can they be added without destroying performance and compatibility?

Some of this already exists, with stuff like stack canaries and address sanitizer. But can it go beyond these ad hoc solutions that catch common mishaps, and become something truly reliable?

It should be possible to just flip a switch on the compiler and have it so that, for example, if you alloca() X bytes and then use the resulting pointer to access byte X+1, that is reliably caught at runtime. And not just as some single patch that specifically looks out for alloca() abuse, but as part of a wider system that understands and catches all out of bounds access.

This is sort of what Cyclone tried, in a way.

Cyclone looks cool, but it's a pretty significant departure from normal C. I'm wondering how far you can take safety without changing the actual language at all. Or rather, how far you can take safety without changing the language and without completely killing performance. Memory safety shouldn't be hard: track all valid regions and pointers to them and don't allow mixing stuff up. But doing it fast is tough.

Have you looked at CCured?

http://www.cs.berkeley.edu/~necula/Papers/ccured_pldi03.pdf

"CCured is a program transformation system that adds memory safety guarantees to C programs by verifying statically that memory errors cannot occur and by inserting run-time checks where static verification is insufficient."

I haven't heard of it before, but that's the sort of thing I'm thinking of, and that looks pretty cool. Looks like the resulting programs still perform reasonably well too.

FYI, Rust has no more of a runtime system than C/C++.

That doesn't mean sticking with the status-quo is the solution.

Rust certainly looks like a better starting point for modern, safe low-level programming than C. C served us quite well for over 40 years, but perhaps it's time to move on...

Reply on news.ycombinator.com