Hacker News Reader

Comment by jacques_chester | Hacker News Reader

C has a number of safety-compromising properties that require positive human effort to counteract.

You can go a long way to counteracting some of these with automated toolchains.

You can probably go further by using languages which simply eliminate certain classes of error and then having the same level of toolchain elaboration.

That's not to say that C code can't be safe. It can absolutely be made safe. It just costs more, and any system that requires positive human effort is more likely to fail than one that doesn't.

View on HN

C has the benefit that it's as close as you can get to a WYSIWYG language. There's no VM or garbage handler running behind your back doing god-knows-what at the most inopportune time. You can look at the code and know exactly what instructions it's going to execute, every time.

(Yes the compiler can do some trickery at certain optimization levels but even then, you're able to look at the generated assembly very easily and verify the output you expect to see).

I'm a little surprised they aren't running their own OS with a custom scheduler; I guess the odds of that being bug free vs the odds of running into a Linux bug make it a losing proposition.

Ada has had hard realtime support since Ada 95.

Also, the idea that C or even Assembler creates guarantees of stability and predictability is contingent on the CPU design.

But now I am at the limits of my shallow pool of knowledge. The SpaceX stuff demonstrably works; Carmack has done fast control systems in C/C++ and it works. I'm probably making an unnecessary fuss.

GA144, from Green Arrays, is a chip which is very good for space applications - computational power, energy efficiency, predictability, versatility, radiation tolerance... Yet after a year and a half on the market there is still no sensible C compiler for it.

I doubt "C is as close as you can get to WYSIWYG" is always entirely correct.

> You can look at the code and know exactly what instructions it's going to execute, every time.

Unless you are talking about embedded processors or old 8 and 16 bit processors, this is no longer true in modern architectures.

That's why they DONT use "modern architectures" in space missions.

Can you name a potentially appropriate language and a class of error it eliminates that cannot be eliminated with automated toolchains in C or C++?

A common example is the incomplete case problem (currently fixed by static analysis tools, I believe, but bear with me).

Suppose you have an enum:

   enum rocket_states { ROCKET_WAITING, ROCKET_FLYING, ROCKET_FAULT }

And a switch that runs off that enum:

    switch ( some_rocket_state ) {
      ROCKET_WAITING:
        wait_foo();
        wait_bar();
        break;
      ROCKET_FLYING:
        fly_foo();
        break;
      }
    }

This will compile. (Or maybe it won't, I haven't cut C for some time now).

But you've missed the ROCKET_FAULT case. In languages which check for case completeness, this kind of logical construction would cause a compiler failure. ML, F#, Rust etc will all complain that you haven't addressed all cases.

Sometimes this or something like it is added to a code template:

      default: assert(false);

Which is defensive code that's great for test. But not as great for rockets. Better if bad code simply can't be written.

I believe static analysis tools can now pick up on missing cases, but there are still lots of reasons why C can't be as fully analysed as a language like ML, Haskell, ATS, Rust etc can be. Putting aside the obvious problem of undefined behaviour meaning you really want to push C code through multiple compilers and multiple static analysis tools, there's also the great universal escape hatch for C: direct memory access.

When you can simply go in and change memory, type systems and analysis are strictly speaking no longer going to work without positive human effort to refrain from doing that. Analysis can only make guarantees under certain assumptions; introduce direct memory access and all bets are off.

Yes, discipline and coding standards can also cut this down. Some analysis tools will do partial analysis of memory accesses. But it still requires positive human action. A computing system includes the humans who make it, run it and use it. Cutting down on the avenues for mistakes is a good thing.

Assuming gcc or similar, -Wall will pick up on this.

    int main() {
      enum states { A, B, C } x = A;
      switch(x) {
        case A: break;
        case B: break;
        // C not handled on purpose
      }
      return 0;
    }

    $ g++ -Wall -Werror -o enum enum.cc
    cc1plus: warnings being treated as errors
    enum.cc: In function ‘int main()’:
    enum.cc:3: warning: enumeration value ‘C’ not handled in switch

I like this behavior since I can deliberately leave out a default and make sure I always have every case handled explicitly.

Thankyou for correcting me. I definitely need to find a better example.

I'm ambivalent about whether to have default cases. The assert(FALSE) trick is still useful for catching missing breaks in the final case.

Thanks for the answer. I'm curious about the implication that there aren't any mature static analysis tools that catch all undefined behavior and memory access to potentially invalid or mis-typed objects. I expect such tools technically could exist but don't know if they actually do.

I might not understand what you mean regarding positive human action when talking about using static analysis tools -- are you referring to tools that require a manual process to run and evaluate, rather than having your tools outright fail to produce a program if static analysis isn't completely happy with the source code?

Positive human action means that somebody must take some action in order for the system to work. That is, effort above a natural baseline. Such systems are not failsafe.

The classic example in C/C++ is avoiding buffer overflow defects. If you code naively to the language, they will creep in. Additional effort is require to apply policies and procedures to prevent such errors from occurring -- enabling warnings, using static analysis, using particular libraries like BString and so on. Further effort is required to ensure compliance.

I use the term "positive" by analogy with legal positivism, which is (very roughly) that law is created by legislative action and doesn't exist until that has occurred. Similarly, many kinds of safety in C don't exist until you have taken that positive step to introduce additional safeguards.

In languages with a more complete view of strings, all of this additional activity is unnecessary. Positive human effort is not required to prevent buffer overflows in such languages. No new procedures, policies, libraries or tools need to be introduced or mandated. The system's baseline configuration is already safe against that class of errors.

Why does this matter?

Two reasons.

Firstly, positive human action is expensive.

Secondly, and this is more important, it's unreliable. Any time your safety depends on somebody always sticking to the rules, always remembering to flick a switch, then safety is not assurable. Humans subvert because they disagree, get distracted, make errors, have simple lapses of memory or judgement and so on.

That you can remedy some or all of these problems through lashing together a large management system is one thing. Whether that was the cheapest overall option is another thing entirely.

Mind you, this is all a bit pie in the sky. Apart from Ada (and even then only partly) I'm not aware of an industrial language that fulfills both my requirements and the requirements of SpaceX that I'm pretending can be solved at a stroke. I suspect Rust will be that language. Let's see.

Reply on news.ycombinator.com