5 ms·

IIRC, 64 bits give you 200 years when you're counting nanoseconds. Why on Earth would they use a 32-bit integer? I doubt this was some kind of microoptimisation

IIRC, 64 bits give you 200 years when you're counting nanoseconds. Why on Earth would they use a 32-bit integer? I doubt this was some kind of microoptimisation. My bet is on some sort of legacy component that is 64-bit-o-phobic.

DocTomoe 8y ago
Of course, in security-relevant areas, prooven legacy code always trumps the new code. Noone wants to lose an airliner because Phil right out of a CS course positively needed a ruby interpreter in the main flight computer... To understand this mindset, have a look at http://www.stroustrup.com/JSF-AV-rules.pdf http://www.stroustrup.com/JSF-AV-rules.pdf
- deleted 8y ago
  [deleted]
- sbradford26 8y ago
  My favorite recommendation to people. Take a C or C++ program they have written and compile it with full MISRA. Definitely makes things more interesting.
  - adrianN 8y ago
    The hardest thing to change after the program is already finished is getting rid of allocations. But other than that MISRA compliance is not that difficult and avoiding allocations is not that difficult either if you plan for it from the beginning.
    - sbradford26 8y ago
      If you know what you are doing it is not difficult, but if you are doing it for the first time it a good tool to learn how to think about all the repercussions of how you program something. MISRA isn't really to catch problems with c it is to catch problems with people using c. So knowing what those problems are and how to avoid them is incredibly useful.
danbruc 8y ago
200 years sounded low to me and so I did the math and it is indeed pretty spot on. 63 bits, i.e. signed integers, will last 292.27 years and you obviously get twice that if you are not interested in negative numbers.
- ainar-g 8y ago
  Right, thanks. My estimate was closer to 200 because I was thinking of Go's time.Time.UnixNano method[1], which returns undefined results when used before the year 1678 or after the year 2262. But yeah, if you count since the system restart, it's bigger. [1] https://tip.golang.org/pkg/time/#Time.UnixNano https://tip.golang.org/pkg/time/#Time.UnixNano
  - danbruc 8y ago
    My gut feeling was more like it should be at least millions of years but my gut was probably thinking in milliseconds or so.
  - deivid 8y ago
    That's just +-292 since 1/1/1970
ajross 8y ago
> Why on Earth would they use a 32-bit integer? Why stop there? Why on earth would anyone use an integer instead of a double, given the inherent risk of truncation error? Or for different arguments: Why on earth would anyone use a 16 bit wchar_t? Why on earth would anyone make char unsigned (or signed)? Why on earth would anyone put the little end first? Machines are machines. They have fixed representations for different types, with tradeoffs. And you have to pick one. And the thing about timeout handling specifically is that everyone along the path from the timer driver up through the app needs to agree on the precision needed, or you'll get an overflow condition. Arguments of the form "Bugs are bad and we shouldn't write them" have not historically helped with improving software quality.
- _verandaguy 8y ago
  I think the comment you're replying to makes a solid point, still. If this bug were to appear every 200 years, that's substantially longer than the lifespan of any single airframe currently in existence (and nearly twice as long as the existence of powered flight) -- and if a Dreamliner were to actually survive that long (most likely as a historical artifact doing heritage flights, maybe), doing this kind of reset would just be part of the routine of getting the "old frame" up and running, not unlike timing certain steps of a WWII fighter plane's manually rather than having them done automatically. Without saying that increasing the width of that variable is the _optimal_ solution, in this case deferring the error leads to safe and predictable operation over the airframe's nominal lifespan. For what it's worth, quadrupling the variable's width to a int128_t would mean you can store over 10^22 years at nanosecond granularity, effectively future-proofing this bug out of existence, and I'm reasonably sure a modern system should be able to spare 3 extra bytes.
- titzer 8y ago
  "Well, I figured....that bridge is gonna fall down in 200 years no matter what, so I went ahead and used rubber bands to hold the suspension lines in place. Only cost me $2!" No, just no. Don't be a hilljack. Build something to spec. 32 bits is clearly not to spec.
  - 8y ago
kilo_bravo_3 8y ago
I was in training brushing up on my embedded programming skills, which thankfully I don't have to use anymore, and the instructor told a story about a bug in a missile that was on the verge of delaying its deployment due to tests failing. While on the bench and being subjected to a bunch of tests to validate the seeker components against simulated targets and countermeasures, the flight control surfaces would start spazzing out after a few minutes in the test jig. The problem had something to do with IR (or something) tracking and attitude control, with the tracker rolling over the odometer and sending spurious data to the flight guidance system which caused the tests to fail and would have lead to an in-flight breakup of the missile real-world. The onboard hardware was highly resource constrained, and engineers and developers worked for weeks trying to fix the problem, going as far as contemplating a complete redesign of the seeker system. Then somebody pointed out that between the time of launch and the missile's two end states: impact with the target or fuel exhaustion-- was less than 60 or so seconds. The only reason the bug was causing problems was that tests were being run back-to-back-to-back in order to speed up things, and the seeker subsystem was being powered on for way longer than it ever would be in the real world. A missile shouldn't have to be on for more than a couple of minutes, and a Dreamliner shouldn't have to be on for more than 248.55 days so I'm willing to bet they stuck some ancient 8-bit micro in there, reused ancient code that was already tested, and called it a day.
- Nimelrian 8y ago
  > a story about a bug in a missile that was on the verge of delaying its deployment due to tests failing. A Patriot Missile in Saudi Arabia wasn't launched to intercept a SCUD, which then killed 28 soldiers. The reason was poor handling of rounding errors [1] The maiden flight of the Ariane 5 rocket resulted in a RUD due to an integer overflow [2] [1] http://www-users.math.umn.edu/~arnold/disasters/patriot.html http://www-users.math.umn.edu/~arnold/disasters/patriot.html [2] http://www-users.math.umn.edu/~arnold/disasters/ariane.html http://www-users.math.umn.edu/~arnold/disasters/ariane.html
  - SiempreViernes 8y ago
    To be fair, there is little public evidence that Patriots ever killed a SCUD (but plenty of public evidence of the Army lying about their effectiveness). http://www.turnerhome.org/jct/patriot.html http://www.turnerhome.org/jct/patriot.html
Symmetry 8y ago
Well, the sort of engineer working on this might very well have gotten their start in environments where they were restricted to 5k of RAM. In that case it's easy to paint yourself into a corner by choosing integer representations that are larger than you need.
nofunsir 8y ago
64-bit-o-phobic... GreenHills INT178, until recently.

DocTomoe 8y ago

Of course, in security-relevant areas, prooven legacy code always trumps the new code. Noone wants to lose an airliner because Phil right out of a CS course positively needed a ruby interpreter in the main flight computer... To understand this mindset, have a look at http://www.stroustrup.com/JSF-AV-rules.pdf http://www.stroustrup.com/JSF-AV-rules.pdf

deleted 8y ago
[deleted]
sbradford26 8y ago
My favorite recommendation to people. Take a C or C++ program they have written and compile it with full MISRA. Definitely makes things more interesting.
- adrianN 8y ago
  The hardest thing to change after the program is already finished is getting rid of allocations. But other than that MISRA compliance is not that difficult and avoiding allocations is not that difficult either if you plan for it from the beginning.
  - sbradford26 8y ago
    If you know what you are doing it is not difficult, but if you are doing it for the first time it a good tool to learn how to think about all the repercussions of how you program something. MISRA isn't really to catch problems with c it is to catch problems with people using c. So knowing what those problems are and how to avoid them is incredibly useful.

danbruc 8y ago

200 years sounded low to me and so I did the math and it is indeed pretty spot on. 63 bits, i.e. signed integers, will last 292.27 years and you obviously get twice that if you are not interested in negative numbers.

ainar-g 8y ago
Right, thanks. My estimate was closer to 200 because I was thinking of Go's time.Time.UnixNano method[1], which returns undefined results when used before the year 1678 or after the year 2262. But yeah, if you count since the system restart, it's bigger. [1] https://tip.golang.org/pkg/time/#Time.UnixNano https://tip.golang.org/pkg/time/#Time.UnixNano
- danbruc 8y ago
  My gut feeling was more like it should be at least millions of years but my gut was probably thinking in milliseconds or so.
- deivid 8y ago
  That's just +-292 since 1/1/1970

ajross 8y ago

> Why on Earth would they use a 32-bit integer? Why stop there? Why on earth would anyone use an integer instead of a double, given the inherent risk of truncation error? Or for different arguments: Why on earth would anyone use a 16 bit wchar_t? Why on earth would anyone make char unsigned (or signed)? Why on earth would anyone put the little end first? Machines are machines. They have fixed representations for different types, with tradeoffs. And you have to pick one. And the thing about timeout handling specifically is that everyone along the path from the timer driver up through the app needs to agree on the precision needed, or you'll get an overflow condition. Arguments of the form "Bugs are bad and we shouldn't write them" have not historically helped with improving software quality.

_verandaguy 8y ago
I think the comment you're replying to makes a solid point, still. If this bug were to appear every 200 years, that's substantially longer than the lifespan of any single airframe currently in existence (and nearly twice as long as the existence of powered flight) -- and if a Dreamliner were to actually survive that long (most likely as a historical artifact doing heritage flights, maybe), doing this kind of reset would just be part of the routine of getting the "old frame" up and running, not unlike timing certain steps of a WWII fighter plane's manually rather than having them done automatically. Without saying that increasing the width of that variable is the _optimal_ solution, in this case deferring the error leads to safe and predictable operation over the airframe's nominal lifespan. For what it's worth, quadrupling the variable's width to a int128_t would mean you can store over 10^22 years at nanosecond granularity, effectively future-proofing this bug out of existence, and I'm reasonably sure a modern system should be able to spare 3 extra bytes.
titzer 8y ago
"Well, I figured....that bridge is gonna fall down in 200 years no matter what, so I went ahead and used rubber bands to hold the suspension lines in place. Only cost me $2!" No, just no. Don't be a hilljack. Build something to spec. 32 bits is clearly not to spec.
- 8y ago

kilo_bravo_3 8y ago

I was in training brushing up on my embedded programming skills, which thankfully I don't have to use anymore, and the instructor told a story about a bug in a missile that was on the verge of delaying its deployment due to tests failing. While on the bench and being subjected to a bunch of tests to validate the seeker components against simulated targets and countermeasures, the flight control surfaces would start spazzing out after a few minutes in the test jig. The problem had something to do with IR (or something) tracking and attitude control, with the tracker rolling over the odometer and sending spurious data to the flight guidance system which caused the tests to fail and would have lead to an in-flight breakup of the missile real-world. The onboard hardware was highly resource constrained, and engineers and developers worked for weeks trying to fix the problem, going as far as contemplating a complete redesign of the seeker system. Then somebody pointed out that between the time of launch and the missile's two end states: impact with the target or fuel exhaustion-- was less than 60 or so seconds. The only reason the bug was causing problems was that tests were being run back-to-back-to-back in order to speed up things, and the seeker subsystem was being powered on for way longer than it ever would be in the real world. A missile shouldn't have to be on for more than a couple of minutes, and a Dreamliner shouldn't have to be on for more than 248.55 days so I'm willing to bet they stuck some ancient 8-bit micro in there, reused ancient code that was already tested, and called it a day.

Nimelrian 8y ago
> a story about a bug in a missile that was on the verge of delaying its deployment due to tests failing. A Patriot Missile in Saudi Arabia wasn't launched to intercept a SCUD, which then killed 28 soldiers. The reason was poor handling of rounding errors [1] The maiden flight of the Ariane 5 rocket resulted in a RUD due to an integer overflow [2] [1] http://www-users.math.umn.edu/~arnold/disasters/patriot.html http://www-users.math.umn.edu/~arnold/disasters/patriot.html [2] http://www-users.math.umn.edu/~arnold/disasters/ariane.html http://www-users.math.umn.edu/~arnold/disasters/ariane.html
- SiempreViernes 8y ago
  To be fair, there is little public evidence that Patriots ever killed a SCUD (but plenty of public evidence of the Army lying about their effectiveness). http://www.turnerhome.org/jct/patriot.html http://www.turnerhome.org/jct/patriot.html

Symmetry 8y ago

Well, the sort of engineer working on this might very well have gotten their start in environments where they were restricted to 5k of RAM. In that case it's easy to paint yourself into a corner by choosing integer representations that are larger than you need.

nofunsir 8y ago

64-bit-o-phobic... GreenHills INT178, until recently.