3 ms·

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

> 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.

woodruffw 4y ago
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.
Groxx 4y ago
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.
- jamincan 4y ago
  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/ https://fosdem.org/2023/schedule/event/rust_coreutils/
  - Groxx 4y ago
    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/product_id-5075/GNU-Coreutils.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...

woodruffw 4y ago

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.

Groxx 4y ago

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.

jamincan 4y ago
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/ https://fosdem.org/2023/schedule/event/rust_coreutils/
- Groxx 4y ago
  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/product_id-5075/GNU-Coreutils.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...