4 ms·

by "safer C", i assume you're talking about the likes of rust et al. I'm actually thinking of variants of C that allow existing code to be used with no or mini

by "safer C", i assume you're talking about the likes of rust et al. I'm actually thinking of variants of C that allow existing code to be used with no or minimal modifications. The "Friendly C" proposal that another commenter linked to is a good example: https://blog.regehr.org/archives/1180 https://blog.regehr.org/archives/1180 It seems like Rust is getting some traction, and that's great, but it's certainly not a drop-in replacement for C.

pjmlp 9y ago
C will always be around, unless we get rid of UNIX and POSIX compatibility layers. Which given Microsoft's sudden love to stay relevant, means that we are at the edge of an UNIX monoculture. So any improvement to make C safer is more than welcome. My preference would be to have something like Frama-C be part of ANSI C.
- pcwalton 9y ago
  Virtually nobody who is not already using Frama-C would start using it as a result of it being added to ANSI C. Ask industry C programmers "why aren't you using theorem provers to prove the correctness of your C code?" The number of them who will give you "because ANSI didn't standardize them" as an answer is zero.
  - pjmlp 9y ago
    I know, but since we are not going to get any UNIX/POSIX variant out there replaced with C++, let alone Rust, we better get ways of improving its safety. Even it means just pilling up safety band-aids. Even Microsoft caved in regarding not supporting C newer than C89, and now have on their Visual Studio roadmap to improve the C support beyond what ANSI C++ requires. https://www.reddit.com/r/cpp/comments/6mqd2e/why_is_msvc_usually_behind_the_other_compilers_in/dk3vu0z/ https://www.reddit.com/r/cpp/comments/6mqd2e/why_is_msvc_usu... They also rewrote their User-Mode Driver Framework (UMDF) from COM/C++ back into C, https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/getting-started-with-umdf-version-2 https://docs.microsoft.com/en-us/windows-hardware/drivers/wd... I am really looking forward to Joe Duffy's keynote at Rustcon, regarding systems programming improvements.
duneroadrunner 9y ago
I can't say for certain why none of the "safer C"s have caught on, but I can say that they all have significant compromises and/or impracticalities. Often, performance cost is one of them. Today though, you can use the safe numerics[1] library along with SaferCPlusPlus[2] (shameless plug) as a high performance solution to address undefined behavior in your C code. This solution preserves most of your C code intact, and there is an auto-translation assistance tool[3] in development to further reduce the effort required. (SaferCPlusPlus currently has a dependency on the standard library, so may not be usable on the most restricted embedded platforms[4].) If performance is not a concern, just compiling with the appropriate sanitizers[5] is an easy option (though not a complete solution). But note that all of these solutions take the position that not only is the undefined behavior itself a problem, but also the operation which instigated the undefined behavior. And there is good reason for that. If you just want the undefined behavior to be defined, then the question is, what exactly are you trying to achieve by doing so? Are you hoping to guarantee deterministic behavior while maintaining portability? [1] https://github.com/robertramey/safe_numerics https://github.com/robertramey/safe_numerics [2] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusplus-versus-clangllvm-sanitizers https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp... [3] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... [4] https://github.com/duneroadrunner/SaferCPlusPlus/issues/3 https://github.com/duneroadrunner/SaferCPlusPlus/issues/3 [5] http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
- pcwalton 9y ago
  There have been lots of solutions like "SaferCPlusPlus" over the years. In my view, the real reasons why these have not been adopted widely are (1) aversion to any sort of runtime overhead greater than zero; (2) cognitive overhead of introducing new language machinery, type-level or otherwise; (3) interoperability with existing code; (4) few people want to be the first to adopt these kinds of tools in production due to the perceived risk; (5) denial that memory safety problems are indeed problems. If you're going for wide usage, I think it's actually easier to start over with a new language rather than to try to graft safety features onto C++. A lot of low-level folks don't realize it, but C and C++ are no longer the behemoths they used to be. If you look at the languages people are switching to rather than just absolute usage share, the usage chart [1] paints a very different picture. [1]: https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png https://blog.sourced.tech/post/language_migrations/eigenvect...

pjmlp 9y ago

C will always be around, unless we get rid of UNIX and POSIX compatibility layers. Which given Microsoft's sudden love to stay relevant, means that we are at the edge of an UNIX monoculture. So any improvement to make C safer is more than welcome. My preference would be to have something like Frama-C be part of ANSI C.

pcwalton 9y ago
Virtually nobody who is not already using Frama-C would start using it as a result of it being added to ANSI C. Ask industry C programmers "why aren't you using theorem provers to prove the correctness of your C code?" The number of them who will give you "because ANSI didn't standardize them" as an answer is zero.
- pjmlp 9y ago
  I know, but since we are not going to get any UNIX/POSIX variant out there replaced with C++, let alone Rust, we better get ways of improving its safety. Even it means just pilling up safety band-aids. Even Microsoft caved in regarding not supporting C newer than C89, and now have on their Visual Studio roadmap to improve the C support beyond what ANSI C++ requires. https://www.reddit.com/r/cpp/comments/6mqd2e/why_is_msvc_usually_behind_the_other_compilers_in/dk3vu0z/ https://www.reddit.com/r/cpp/comments/6mqd2e/why_is_msvc_usu... They also rewrote their User-Mode Driver Framework (UMDF) from COM/C++ back into C, https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/getting-started-with-umdf-version-2 https://docs.microsoft.com/en-us/windows-hardware/drivers/wd... I am really looking forward to Joe Duffy's keynote at Rustcon, regarding systems programming improvements.

duneroadrunner 9y ago

I can't say for certain why none of the "safer C"s have caught on, but I can say that they all have significant compromises and/or impracticalities. Often, performance cost is one of them. Today though, you can use the safe numerics[1] library along with SaferCPlusPlus[2] (shameless plug) as a high performance solution to address undefined behavior in your C code. This solution preserves most of your C code intact, and there is an auto-translation assistance tool[3] in development to further reduce the effort required. (SaferCPlusPlus currently has a dependency on the standard library, so may not be usable on the most restricted embedded platforms[4].) If performance is not a concern, just compiling with the appropriate sanitizers[5] is an easy option (though not a complete solution). But note that all of these solutions take the position that not only is the undefined behavior itself a problem, but also the operation which instigated the undefined behavior. And there is good reason for that. If you just want the undefined behavior to be defined, then the question is, what exactly are you trying to achieve by doing so? Are you hoping to guarantee deterministic behavior while maintaining portability? [1] https://github.com/robertramey/safe_numerics https://github.com/robertramey/safe_numerics [2] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusplus-versus-clangllvm-sanitizers https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp... [3] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla... [4] https://github.com/duneroadrunner/SaferCPlusPlus/issues/3 https://github.com/duneroadrunner/SaferCPlusPlus/issues/3 [5] http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

pcwalton 9y ago
There have been lots of solutions like "SaferCPlusPlus" over the years. In my view, the real reasons why these have not been adopted widely are (1) aversion to any sort of runtime overhead greater than zero; (2) cognitive overhead of introducing new language machinery, type-level or otherwise; (3) interoperability with existing code; (4) few people want to be the first to adopt these kinds of tools in production due to the perceived risk; (5) denial that memory safety problems are indeed problems. If you're going for wide usage, I think it's actually easier to start over with a new language rather than to try to graft safety features onto C++. A lot of low-level folks don't realize it, but C and C++ are no longer the behemoths they used to be. If you look at the languages people are switching to rather than just absolute usage share, the usage chart [1] paints a very different picture. [1]: https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png https://blog.sourced.tech/post/language_migrations/eigenvect...