Hacker News Reader

Comment by Groxx | Hacker News Reader

I believe their (and this thread's) original point was that even absurdly widely used, studied, and continuously fuzzed C tools written and maintained by many serious experts for decades....

... still have multiple easily-uncovered memory issues.

Nobody writes safe C. Believing otherwise is delusional. This has been known for decades. But many believers still exist.

View on HN

> Nobody writes safe C. Believing otherwise is delusional. This has been known for decades. But many believers still exist.

This is factually incorrect. You can write safe C code which is even correct according to some specification, as in "guaranteed bug free". This is not what most people do (or even know how to do) though.

I'm not aware of a generalized safe subset of C. There are lots of compiler extensions and model annotations that offer security improvements, but very few will claim to offer spatial and temporary memory safety in the way that safe programming languages can.

There are lots of specification driven C applications, which rely on (1) the specification being bug free, (2) the application of the specification being bug free, and (3) the model or proof assistant for the specification being sound and bug free. Getting all three of those is historically very difficult.

No realistic code that does that exists AFAIK. It may have sections that do it (which is great!), but not a total useful binary.

It's a straw-man that's trotted out every time, and it's utterly meaningless beyond academic arguments. Even if it is true, it's not relevant for any practical purposes.

In the FOSDEM presentation about Rust coreutils, they mentioned that security concerns were not a motivating factor for the rewrite - the C implementation has had only 17 CVEs since 2003.

https://fosdem.org/2023/schedule/event/rust_coreutils/

That's a very positive sign for the quality of coreutils, but does exactly nothing to assert there are no flaws.

And I'll point to CVE-2015-4041 as evidence in my favor - that's a buffer overflow: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...

Reply on news.ycombinator.com