Hacker News new | comments | show | ask | jobs | submit login
Of Aviation Crashes and Software Bugs (2008) (duartes.org)
26 points by Someone 7 months ago | hide | past | web | favorite | 15 comments

The linked Daniel J. Bernstein paper [0] is interesting. I note with some satisfaction that section 3.2 echoes a comment I made last week [1] that wound up at -1 (after some bouncing around). Arbitrary-precision integers should be the default in all new languages, with very few exceptions (and should clearly have been the default in Java).

Rust is an interesting case. It's intended as a systems programming language, so performance is considered important. I guess I can't say flatly that it should have arbitrary-precision integers by default, though maybe it could. But at least it reminds you, every time you write an integer type, that it's bounded, the length being right there in the type name ("i32", "u64", etc.)

[0] http://cr.yp.to/qmail/qmailsec-20071101.pdf

[1] https://news.ycombinator.com/item?id=14906755

The problem is not at all with the precision, but rather with the undefined behavior in certain circumstances.

If that can be avoided it makes no sense to use the slow and wasteful bigints.

Arbitrary-precision integers are not that slow if they're implemented the way most Lisp implementations do it. For a strongly-typed language, you would need only one tag bit: if the low-order bit is 0, then the remaining bits of a pointer-sized word, shifted right 1 bit, are the value; no heap storage or indirection is required, and addition and subtraction require no fixup afterwards as long as there was no overflow. Only if the low-order bit of an operand is 1, or if there's overflow, do you have to trap out to the general case which handles heap allocation.

Yes, this is slower than ordinary fixed-width integer arithmetic, as a couple of conditional branches are required, but it's nowhere near the price of heap-allocating every integer.

And the overflow check is now finally cheap in portable C. Before you had to use inline assembly for this trivial ex:

    add %rax, %rbx
    jo +4
Now you have the new gcc and clang overflow intrinsics (gcc-5, clang-3.4), which made it cheap and easy to use proper and precise int arithmetic, promoting int to bigint's only on overflow.

That's clever, stuff like that which is so blindingly simple in hindsight is why I always feel like an impostor in the low level world :)

Civil aviation aircraft still fly 1930's engine designs in 1950's airframes, and the costs are prohibitive. Sure sounds like a great model for software... For example, a typical ~200HP aviation engine costs on the order of $30,000 and has no modern engine management systems.

This article makes a false comparison. When software is part of safety, such as in aircraft, it gets the same level of scrutiny.

> When software is part of safety, such as in aircraft, it gets the same level of scrutiny.

Safety? For the most part, yes. Security? Not so much.

Idiotic to compare systems on which human lives depend to everything else.

There's no one-size fits all. Speed and accuracy tend to have an inverse correlation.

You're missing the point. It's not about the system type, but rather the approaches taken to analyse system failures and the subsequent corrective actions.

His criticism still applies to today's projects: recently I've seen fixes in imagemagick done as minimal "patches".

I've seen patches in production code that amount to 20 if else's to handle specific inputs rather than the correct input.

I just inherited a system that uses trim everywhere on everything because originally they didn't sanitise the inputs.

Rather than hunt down all the inputs they just did trim(foo) == trim(bar) making it worse is that it's PHP and so not only do they trim things but they type-coerce them, good luck trying to reason about that 7 layers deep :|

> Speed and accuracy tend to have an inverse correlation.

Inaccurate speed is only of limited usefulness, but the bigger problem is when you don't get either.

In the plane crash that killed Colbert's father the pilots were arguing about politics. If thats not ironic I don't know why is.

The choice of language for a project is the least problematic thing in this industry. Egotistical programmers, the categorical error of equating CS fundamentals with engineering, rapid product development and iteration, and producing as cheaply as possible all are more serious problems in this industry than a choice of language to program in.

It's related because the languages and toolchains come from that industry.

The article is far too long winded for my taste.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact