11 ms·

>> Checked C isn’t C. According to the paper, it is: "Checked C is backward compatible with legacy C in the sense that all legacy code will type-check and com

>> Checked C isn’t C. According to the paper, it is: "Checked C is backward compatible with legacy C in the sense that all legacy code will type-check and compile. However, only code that appears in checked regions, which we call checked code, is spatially safe. Checked regions can be designated at the level of files, functions, or individual code blocks, the first with a #pragma and the latter two using the checked keyword. Within checked regions, both legacy pointers and certain unsafe idioms (e.g., variadic function calls) are disallowed." >> I’ve yet to see a convincing reason to use it instead of, say, Go. Or Rust, if you want real safety. What if you have a legacy codebase with hundreds of thousands of lines of C you want to maintain and improve? What if Go, Rust, etc. are not supported on your target platform?

tialaramex 5y ago
> What if you have a legacy codebase with hundreds of thousands of lines of C you want to maintain and improve? We know that smaller projects have successfully gone on the journey of moving from C to Rust, and they did so the same way you a whale right? One bite at a time. So that might absolutely be a reasonable choice. Things that could make it especially attractive: * There's existing Rust skill set in your team and not checked C * You intend to do other new work in Rust, so this is a skill set you'll be needing anyway. * There is relevant existing work in Rust e.g. today you use a popular C library for processing radar data. You know an equivalent library (or a port of the C library) is available as a Rust crate, if you went with Checked C, either the library isn't checked (partly undoing the good work) or you have to also translate the third party library to checked C. * The main benefit you were looking for is something checked C doesn't care about e.g. freedom from data races is a pretty big deal for concurrent software, and checked C doesn't do that today, and has no plans to do it in future but such races aren't possible in (safe) Rust. Or you wish you had nice built-in features like iterators. * Or the opposite side of the same coin, the main thing you dislike about C is still present in checked C. Maybe you don't like C's silent wrapping overflow, in checked C it's still there, but in Rust you can switch it off. Maybe you don't want the integer fifteen to be silently considered boolean "true" because you thought this programming language was supposed to have type checking, Rust is with you on that, Checked C of course is not.
- thesuperbigfrog 5y ago
  If it makes sense to move to Go, Rust, or something else, and the constraints you are working under allow it, by all means do so. Not everyone has those options, so any tools that can help within the limitations (such as Checked C) are welcome.

tialaramex 5y ago

> What if you have a legacy codebase with hundreds of thousands of lines of C you want to maintain and improve? We know that smaller projects have successfully gone on the journey of moving from C to Rust, and they did so the same way you a whale right? One bite at a time. So that might absolutely be a reasonable choice. Things that could make it especially attractive: * There's existing Rust skill set in your team and not checked C * You intend to do other new work in Rust, so this is a skill set you'll be needing anyway. * There is relevant existing work in Rust e.g. today you use a popular C library for processing radar data. You know an equivalent library (or a port of the C library) is available as a Rust crate, if you went with Checked C, either the library isn't checked (partly undoing the good work) or you have to also translate the third party library to checked C. * The main benefit you were looking for is something checked C doesn't care about e.g. freedom from data races is a pretty big deal for concurrent software, and checked C doesn't do that today, and has no plans to do it in future but such races aren't possible in (safe) Rust. Or you wish you had nice built-in features like iterators. * Or the opposite side of the same coin, the main thing you dislike about C is still present in checked C. Maybe you don't like C's silent wrapping overflow, in checked C it's still there, but in Rust you can switch it off. Maybe you don't want the integer fifteen to be silently considered boolean "true" because you thought this programming language was supposed to have type checking, Rust is with you on that, Checked C of course is not.

thesuperbigfrog 5y ago
If it makes sense to move to Go, Rust, or something else, and the constraints you are working under allow it, by all means do so. Not everyone has those options, so any tools that can help within the limitations (such as Checked C) are welcome.