5 ms·

> is it something that any similar language would have to contend with? it's something any language could _potentially_ have to deal with. C's penchant for und

> is it something that any similar language would have to contend with? it's something any language could _potentially_ have to deal with. C's penchant for undefined behavior comes from two factors, i think: 1. it's ancient. we've learned a lot of lessons since its inception about how to design a language. it also comes from a time when CPU architectures varied wildly -- even within a given manufacturer's product line. 2. the developer culture during the time when C was being designed was of the "i don't want a language to tell me how to write code. if it's possible in assembly, i want to be able to do it in C." mentality. > is that because the problem really is intractable? by "safer C", i assume you're talking about the likes of rust et al. C is used largely in the embedded space, and the embedded space, i think, is notoriously stuck in their ways. most embedded projects accrue a lot of third-party code (the kernel being a big one) and that code is written in C. so you already need C developers. why wander into unexplored territory, especially when it's at the cost of an additional necessary skill from your developers?

iainmerrick 9y ago
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...
jabl 9y ago
> 1. it's ancient. we've learned a lot of lessons since its inception about how to design a language. True, but even so, one of the most damning things about C is that it wasn't even "state of the art" back when it was designed. See https://pastebin.com/UAQaWuWG https://pastebin.com/UAQaWuWG
- rofex 9y ago
  Very interesting, thanks for the link!
pjmlp 9y ago
This is also what helped C win mindshare in the early days of UNIX's adoption across companies. After UNIX vendors started selling their SDKs, the C SDK was a must have anyway, given the relationship of UNIX and C. However, getting the Lisp, Fortran, Pascal, Modula-2, Ada compilers, meant buying them as additional modules, each worth several thousands of whatever currency. The majority of them sold by third parties.

iainmerrick 9y ago

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

jabl 9y ago

> 1. it's ancient. we've learned a lot of lessons since its inception about how to design a language. True, but even so, one of the most damning things about C is that it wasn't even "state of the art" back when it was designed. See https://pastebin.com/UAQaWuWG https://pastebin.com/UAQaWuWG

rofex 9y ago
Very interesting, thanks for the link!

pjmlp 9y ago

This is also what helped C win mindshare in the early days of UNIX's adoption across companies. After UNIX vendors started selling their SDKs, the C SDK was a must have anyway, given the relationship of UNIX and C. However, getting the Lisp, Fortran, Pascal, Modula-2, Ada compilers, meant buying them as additional modules, each worth several thousands of whatever currency. The majority of them sold by third parties.