
Some Boeing 737s can't land on some runways with true heading 270 [pdf] - ColinWright
http://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf/0/3948342a978cc27b862584dd005c1a60/$FILE/2019-25-17.pdf
======
joncrane
Isn't this a duplicate of a post within the past few weeks? I remember this.

~~~
taspeotis
[https://news.ycombinator.com/item?id=21991087](https://news.ycombinator.com/item?id=21991087)

~~~
joncrane
Thank you!

------
reilly3000
This makes me wonder how long it would take for a competent technical leader
to course-correct the culture and product issues that have crept in at Boeing.
It seems to me it would be on the order of years to get their house in order
to get quality to where it should have been.

~~~
bradhe
> competent technical leader to course-correct the culture and product issues
> that have crept in at Boeing.

This issue looks to be a pretty run-of-the-mill bug in their software. It's
likewise scoped down pretty far--there only exist a few runways (in US,
Colombia, and Guayana) that make this relevant. ADs like this come out all the
time.

~~~
eggy
I get the gist of what you are saying about it being par for the course, but
can you explain why a heading of 270 (West if 0 is North)would affect air
worthiness? Is it something to due with true North vs. magnetic north
deviations? Grasping here. I am truly curious about this one. Thanks!

~~~
jonas21
It affects airworthiness because the displays went blank when certain ILS
approaches with heading 270 were selected. This is unexpected and would
require the flight crew to fall back on other instruments.

The FAA routinely issues airworthiness directives for all sorts of safety
issues. Here are a few others published in the past week or so:

[https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf...](https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf/0/f0ddb5e68a9223aa862584ff00566373/$FILE/2020-01-17.pdf)

[https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf...](https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf/0/f44c3d2f513d5268862584f900515e04/$FILE/2020-01-14.pdf)

[https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf...](https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf/0/4aea68db57652880862584f900515ce0/$FILE/2019-26-01.pdf)

[https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf...](https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf/0/85e929ccd96d5695862584f900515b4c/$FILE/2019-25-20.pdf)

------
nabla9
F-22 had similar weird bug. Instead of degrees it was dates.

In 2007 squadron (12) of F-22's were flying from Hawaii to Japan. When they
crossed when they crossed international date line every plane had systems
crash. They lost communication-, fuel-, and navigation subsystems and restart
did not solve the problem. Apparently only basic aviation systems worked. They
could still fly.

They would have been completely lost, but luckily tanker escorting them was
still nearby. They were able to follow it back to the base.

------
et2o
It's a software bug that affects 7 runways worldwide due to a combination of
heading and lat/long.

~~~
xxpor
That does bring up an interesting point. There's only so many airports in the
world (especially ones that can support a 737). You'd think that'd be easy to
exhaustively test if you wanted to.

------
tzs
Would a viable workaround be to tell it the heading is 269 or 271? You’d land
at a slight angle which would have you moving about 17 m toward an edge of the
runway for every km down the runway you go. That seems mild enough for the
pilots to correct once they are on the ground.

------
0xff00ffee
FTA: "All six display units (DUs) blanked with a selected instrument approach
to a runway with a 270-degree true heading, and all six DUs stayed blank until
a different runway was selected."

Holy f-cking f-ck.

------
Waterluvian
Do any languages (like Rust, maybe) force you to guard against the possibility
of a variable being zero if it sees you're dividing by that variable?

And if not the compiler, are there popular static analyzers for any languages
that do so?

~~~
gpm
Rust doesn't by default, though you could certainly make a wrapper type that
does. You could do the same in any language that has algebraic data types
(rust enum's), or another sensible way of forcing you to check certain kinds
of errors.

~~~
Waterluvian
I'll have to experiment with implementing that as well as how Rust divides by
zero. Thanks for sharing.

My probably wrong understanding is that the philosophy behind Rust is that
code without IO/unsafe shall not panic. It might provide useless results but
it won't panic. But dividing an integer by zero causes a panic (if I recall).

Edit: derp. Of course they can panic. You really can't guard against overflow
or OOM and such. gpm helped correct my thinking: it's not about avoiding
panics, it's about avoiding undefined behaviour, forcing you to define all
possible branching paths.

~~~
gpm
Safe rust code is allowed to panic, the standard library does in many places,
and the language does if you overflow normal arithmetic while debug assertions
are on (if debug assertions are off, overflows result in wrapping instead).

What safe code isn't allowed to result in is undefined behavior. Panics are
defined, they just happen to be defined to print an error message and abort
the program (by default, slightly simplified version of how they work).

By the way: If you want to handle overflows you can use methods like
`checked_add`, or you could do something like the suggestion for division by
zero and create a wrapper type that always does `CheckedI32 + CheckedI32 ->
Option<CheckedI32>` (or something). I might implement `Option<CheckedI32> \+
Option<CheckedI32> -> Option<CheckedI32>` as well so you can delay checking
for overflow/division by zero until you want to use the result of the
arithmetic.

~~~
chewxy
> ...does if you overflow normal arithmetic while debug assertions are on (if
> debug assertions are off, overflows result in wrapping instead).

What I am reading from this is that in Rust, debug assertions cause a
different semantics. That does not sound right at all.

~~~
Yen
The debug assertions can panic on code which has defined behavior in
production, but behavior that's probably wrong, and probably would be asserted
in production if it weren't too expensive.

For example, if you do "u32::INTEGER_MAX + 3" in debug, it will panic, but in
production code it will not (and will use the underlying CPU's result of "2")

In most scenarios, this is not actually what you want. If your program has the
possibility of doing arithmetic near or past the bounds, _you_ should define
the semantics you need.

I.e., you can use one of saturating_add, wrapping_add, checked_add, or
overflowing_add, depending on the semantics that are correct for your
application. All of these behave the same between dev and prod.

