4 ms·

My experience in the aerospace industry may or may not be more widely applicable, but here are my two cents. Using "better more safe programming languages" gen

My experience in the aerospace industry may or may not be more widely applicable, but here are my two cents. Using "better more safe programming languages" generally gets you [some greater level of] memory safety and thread safety. Developing for safety-critical embedded systems with a single thread and no dynamic memory allocation renders those benefits irrelevant. There are still concerns around type safety, but full compiler warnings and strict code review, both of which we need regardless, handle that. We also need to be able to certify not only that our source code matches our requirements, but that our binaries match our source code. Compiling with --c99 --debug -O0 gives us a highly visible link between each line of source code that goes into the compiler and the assembly instructions that come out of the compiler. We know exactly what the computer is actually doing, not just what we think we've told it to do. The various "better" languages all get "better" via more powerful and clever (read: complex and opaque) compilers, which is a no-go in our field. With little benefit and impermissible cost to the alternatives, and the breadth and depth and longevity of the resources and support available for it, there's no sane choice for us but C.

suprjami 4y ago
This is a great reply. I'd never considered that part of this field was reverse engineering your own program to confirm the compiler actually emits what you asked it to.
wizofaus 4y ago
There's sense in this if you don't trust compilers/ interpreters in other languages to be reliably doing the right thing, which is certainly a reason to be wary of languages that are new or aren't super widely used. But the amount of effort that goes into ensuring Go or Rust or Ada compilers always generate the correct underlying machine code is surely far more than your own team can achieve, and if there were bugs in such compilers you'd be extraordinarily unlucky to be the first devs affected by them. Also are you saying the final shipped product is built with all the debug flags on (and optimisation flags off)? If not, how do you trust those binaries- trying to match machine code output with C source when optimizations are on (and key debug info stripped) is virtually impossible much of the time.
- jbms 4y ago
  If the debug code with no optimisations is the one trusted most, that's what ships. If the optimiser drops off some code as it thinks it has no effect, I'd guess that's possible to spot, and you'd want to know to either fix the code or remove dead code. I've not personally had to inspect compiler output but I do spend a surprising amount of time in linker map files understanding what's going on.
  - wizofaus 4y ago
    Optimising compilers do a lot more than drop code with no effect (and TBH most decent linter tools will pick that up for you anyway), I've seen them generate machine code that bore virtually no relationship to the C source, with loop unrolling, function call inlining, operation interleaving etc. etc. https://cacm.acm.org/magazines/2020/2/242347-optimizations-in-c-compilers/fulltext https://cacm.acm.org/magazines/2020/2/242347-optimizations-i... has some interesting examples.
    - flyingfences 4y ago
      Yup, and that's exactly why we turn the optimizations off and keep them off, even for the shipped release.
      - wizofaus 4y ago
        Makes sense if safety is a priority over performance and/or concerns over reverse engineering.
        jstimpfle 4y ago
        For the mostly high-level C code that I write, I find that compiler optimisations give typically give speed-ups in the 1.5x - 3x range. A lot of code is bound by external bottlenecks that would completely mask such a speedup anyway. For really performance-oriented code you probably want to drop to SIMD first, and play with compiler optimisations second.

suprjami 4y ago

This is a great reply. I'd never considered that part of this field was reverse engineering your own program to confirm the compiler actually emits what you asked it to.

wizofaus 4y ago

There's sense in this if you don't trust compilers/ interpreters in other languages to be reliably doing the right thing, which is certainly a reason to be wary of languages that are new or aren't super widely used. But the amount of effort that goes into ensuring Go or Rust or Ada compilers always generate the correct underlying machine code is surely far more than your own team can achieve, and if there were bugs in such compilers you'd be extraordinarily unlucky to be the first devs affected by them. Also are you saying the final shipped product is built with all the debug flags on (and optimisation flags off)? If not, how do you trust those binaries- trying to match machine code output with C source when optimizations are on (and key debug info stripped) is virtually impossible much of the time.

jbms 4y ago
If the debug code with no optimisations is the one trusted most, that's what ships. If the optimiser drops off some code as it thinks it has no effect, I'd guess that's possible to spot, and you'd want to know to either fix the code or remove dead code. I've not personally had to inspect compiler output but I do spend a surprising amount of time in linker map files understanding what's going on.
- wizofaus 4y ago
  Optimising compilers do a lot more than drop code with no effect (and TBH most decent linter tools will pick that up for you anyway), I've seen them generate machine code that bore virtually no relationship to the C source, with loop unrolling, function call inlining, operation interleaving etc. etc. https://cacm.acm.org/magazines/2020/2/242347-optimizations-in-c-compilers/fulltext https://cacm.acm.org/magazines/2020/2/242347-optimizations-i... has some interesting examples.
  - flyingfences 4y ago
    Yup, and that's exactly why we turn the optimizations off and keep them off, even for the shipped release.
    - wizofaus 4y ago
      Makes sense if safety is a priority over performance and/or concerns over reverse engineering.
      - jstimpfle 4y ago
        For the mostly high-level C code that I write, I find that compiler optimisations give typically give speed-ups in the 1.5x - 3x range. A lot of code is bound by external bottlenecks that would completely mask such a speedup anyway. For really performance-oriented code you probably want to drop to SIMD first, and play with compiler optimisations second.