Thanks for the reference. I'm always interested in these kinds of things. I'm surprised blame wasn't also placed on the design for making it possible to reverse the controls.

I'm amazed they managed to land it successfully. Those pilots ought to get a medal for flying skill, along with the brickbats for failing to preflight the airplane properly.

Probably the only reason they didn't crash it was the spoilers were set up correctly, and countered some of the aileron bad movement.

On 8/25/2022 10:32 AM, Adam D Ruppe wrote:
> I found the story again, here's the wikipedia article on it that has its references too:
> 
> https://en.wikipedia.org/wiki/Air_Astana_Flight_1388
> 
> "The investigation revealed that the aileron cables were installed incorrectly."
> 
> Only a few years ago too, in 2018!
> 
> There's youtube videos too talking about it too:
> 
> https://www.youtube.com/watch?v=5ywaMkMTwWk (this guy generally goes over the incident report with some nice animations to explain it too)
> https://www.youtube.com/watch?v=kIc8Rr-cKd8 (atc recording part 1)
> https://www.youtube.com/watch?v=evYLkhxoP3U (part 2)
> 
> i know im pretty far off topic but i just enjoy these aviation things.

On 8/25/2022 10:38 AM, Steven Schveighoffer wrote:
> 0 is no better here *but also no worse*.

0 is equal or worse than NaN. It is true that sometimes 0 is equal. But it is *never* better.

BTW, hex data doesn't have a NaN value. But a popular thing we'd do is initialize it to:

  0xDEADBEEF

which is pretty unlikely to occur in the wild. So when dumping hex data, and DEADBEEF is in there, you're very likely looking at uninitialized data getting into the output.

I'd use it for both initializing malloc'd data before returning it to the caller, and setting free'd data to it. It was pretty effective at flushing out uninitialized allocated data, and use-after-free bugs.

Using 0x00 was nowhere near as effective.

On 8/25/2022 11:13 PM, bauss wrote:
> That's why my response to it said it should be Error and not Exception, your program is effectively dead if you ever operate on NaN.

NaN has another use. If, say, your data collection is incomplete (like having a dead pixel in an array of sensors), giving that data point a NaN helps show what part of the results of the data analysis is dependent on the missing data.

On Friday, 26 August 2022 at 01:01:24 UTC, Walter Bright wrote:
> On 8/25/2022 10:38 AM, Steven Schveighoffer wrote:
>> 0 is no better here *but also no worse*.
>
> 0 is equal or worse than NaN. It is true that sometimes 0 is equal. But it is *never* better.
>
>
> Using 0x00 was nowhere near as effective.

This seem be another string auto-decode problem to a basic type. It should implement similar to CheckedInt (as CheckedFloat?) for each case usage; not shoe horn into all use-cases

On 8/26/2022 9:28 AM, Steven Schveighoffer wrote:
> I fully don't ever expect any changes to come from this discussion.

True. I don't believe I've ever managed to change your mind!

> That's great. Now how do you find out where the problem starts?

The most important part is discovering that I *have* a problem.

Next, I grep for DEADBEEF in the source code. And go from there.

I am not making this up for the n.g. I have a *lot* of experience with it. I'm pointing out techniques that work. DEADBEEF turns a heisenbug into a reproducible bug. If it is reproducible, it is findable and fixable.


> What if DEADBEEF is in your dump, but it's just memory that isn't being used yet? Is it still a problem?

That depends on how you were using it.


> Note that this solves a mostly different problem -- using dangling pointers. This isn't about initialization.

It is. The first use case I mentioned was initializing data returned from malloc to DEADBEEF. malloc returns uninitialized data, and I wanted to make sure it wasn't data that just happened to be 0 and "work", because therein lies heisenbugs and madness.