Hacker News Reader

Comment by winter_blue | Hacker News Reader

> However, the rust/LLVM compiler pipeline is nowhere near mature enough for use in high-criticality environments.

I don't know about Rust, but LLVM isn't mature? Nearly ever program running in the Apple ecosystem was compiled using LLVM. Swift is compiled using LLVM. Since Xcode 4.2, Clang is the default compiler. So iOS and macOS apps are built with LLVM. I'd also wager a guess that Apple uses Clang to compile key system code (Darwin, macOS, and iOS, etc) as well.

View on HN

LLVM is still in disagreement as to whether or not infinite loops are UB [1], and others.

It is becoming more mature... But the argument about how to handle an empty infinite loop has been going on since 2015.

[1] https://bugs.llvm.org/show_bug.cgi?id=24078

Offhand thought of the day. The Motor Industry Software Reliability Association should ban compilers that allow optimization based in UB.

Because seriously these people need to be stopped.

UB was invented for the purpose of optimizing. No UB, no optimizing. And nobody is interested in funding or working on compilers that don't optimize.

Anyway, just test with ubsan and you'll be good.

At least a lot of it was due to having to specify around the weird quirks of existing compiler implementations. C has far more undefined behavior than it needs for optimization, and modern programming language theory and compiler research has shown that most undefined behavior isn't really necessary at all. [0] For example, safe Rust has extremely close (and sometimes superior) performance to C, and has almost* no undefined behavior at all. [1]

[0] https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

* Some is inherited from LLVM, some is bugs, some is dumb corner cases like using kernel syscalls to overwrite the program's own memory with random bits.

Name one example where UB is necessary for useful optimizations where simply having unspecified values or platform dependent behavior wouldn't be enough.

Another factor is that Rust is testing LLVM's codepaths in ways that Clang rarely does. A lot of bugs in LLVM have been uncovered through Rust.

I don't think consumer OSes are considered highly critical.

(Unlike code running for avionics for example)

MacOS and related don't run the airplane. Pilots have an iPad for some checklists and other things where "have you tried turning it off and on again" works as failure prcedure. If a failure, caused by a compiler bug leading to an overflow in a rare flight situation, happens on an airplane system a reboot is not really the option you want to depend on.

Ironically, I recall reading about a mid-flight incident where the procedure to bring things back involved turning the entire plane off and on again.

That might work in a stable situation - many (not all) planes are good gliders. (I.e. somewhere I read that the A380 is a quite good glider, among other reasons since the wings were designed for larger versions; an F-16 however won't really glide)

In a critical situation this is impossible, though.

That will not always work very well, inertial navigation systems often wants to be completely still for a couple of minutes to calibrate themselves.

I have heard about just flying with no G-load for a while and getting some basic instruments working. But I dont think you will get full nav functionality back.

I write software for in cockpit ipad apps - they are becoming more and more integral to the workload of pilots, everything from route planning, guidance, checklists, manifests and ordering fuel.

There was actually an incident posted on HN a while ago where IIRC an ipad did a software update or similar at a critical moment, and caused complications bad enough to get an incident report published on some aviation agency's website.

Not mission-critical, must-never-fail mature, no. All of these systems contain tens (if not thousands of bugs), some of these probably come from compiler issues sometimes.

Reply on news.ycombinator.com