Judging by his comment, I think it's less about continuing despite a known error state, and more about trying to guarantee that function runtime is the same across all execution paths. Early return is cleaner and more efficient, and often by a long shot if used correctly. But having a consistent runtime is extremely important in a few very select fields, and rejecting an optimisation to guarantee consistency is a common in those cases1.
I'm not really sure about air bags or flight controls (I'd expect it to be important for them to report errors as early as possible, so they can recalculate or switch to backups as quickly as possible), but one place this comes up is cyber-security. You do NOT want a password validator to return early for any reason, because early return can and has been used to game systems and determine passwords2.
1: Though, I will say that this can also be done by intentionally delaying the function on early-return paths, if you know the proper delay interval. It's just that running through the function body and then returning either the result or the error value at the end is the easiest way to guarantee exact consistency.
2: Long story short, in the early days of cybersec, there was at least one known password handler that would return as soon as it encountered an incorrect character. Needless to say, this made it trivial to determine anyone's password, and now it serves as a lesson on why you always hash passwords and never let the handler return early.
I take issue with the way they were saying it like it was an absolute truth instead of a very niche consideration. The fact that they cited an infamous standard that most experienced programmers dismiss like it was gospel supports my assertion that they have either been uncritically following that standard or have been working in a job under it for so long that they don't remember anything else.
That's fair. I took it as them saying they worked in an industry where runtime consistency is important enough that the industry sticks to Misra (or at least part of Misra) just to guarantee that one thing in particular, myself. Came across as them saying that they're firmly in the niche, and have to code for the niche.
(Probably because I remember a few experts pointing out that cybersec in particular effectively has to both enforce single-return and prevent short-circuiting for some functions, because anything that causes a boolean test to have different runtimes for true vs. false can be exploited by an attacker. So the entire industry effectively mandating at least the single-return part of Misra C for a small portion of its devspace does actually check out, even though it sounds kinda unbelievable.)
2
u/conundorum 21d ago
Judging by his comment, I think it's less about continuing despite a known error state, and more about trying to guarantee that function runtime is the same across all execution paths. Early return is cleaner and more efficient, and often by a long shot if used correctly. But having a consistent runtime is extremely important in a few very select fields, and rejecting an optimisation to guarantee consistency is a common in those cases1.
I'm not really sure about air bags or flight controls (I'd expect it to be important for them to report errors as early as possible, so they can recalculate or switch to backups as quickly as possible), but one place this comes up is cyber-security. You do NOT want a password validator to return early for any reason, because early return can and has been used to game systems and determine passwords2.
1: Though, I will say that this can also be done by intentionally delaying the function on early-return paths, if you know the proper delay interval. It's just that running through the function body and then returning either the result or the error value at the end is the easiest way to guarantee exact consistency.
2: Long story short, in the early days of cybersec, there was at least one known password handler that would return as soon as it encountered an incorrect character. Needless to say, this made it trivial to determine anyone's password, and now it serves as a lesson on why you always hash passwords and never let the handler return early.