News for hackers. Stuff that matters.
Re:Integer Overflow Bug in Boeing 787 Dreamliner by ambrop7 on Saturday May 02, 2015 @07:09AM (#9476644)
A general solution to the overflowing-clock problem is to deal with the clock in modular arithmetic. When wanting to know if t2 comes before t1, check the MSB of the modular difference.

  uint32_t t1 = ...;
  uint32_t t2 = ...;
  if ((uint32_t)(t2 - t1) >= UINT32_C(0x80000000)) {
    // t2 is before t1
  } else {
    // t2 is after or equal to t1
  }
What this gives us is that if the difference of the actual times (not these uint32 representations which are ambiguous modulo 2^32) is less than 2^31 units (plus minus one maybe..), this check will give the expected result. This does allow a correct system that never fails if the timing/duration of the events is suitably limited.

For example you time events at a fixed time interval, and it will keep going forever in spite of clock roll-over.

  uint32_t next_time = now();
  while (1) {
    while ((uint32_t)(now() - next_time) >= UINT32_C(0x80000000));
    printf("Shoot\n");
    next_time += interval;
  }
The timing events also need to be processed quickly enough of course (that printf shouldn't block for longer than about 2^31).
Re:Integer Overflow Bug in Boeing 787 Dreamliner by tlb on Saturday May 02, 2015 @07:36AM (#9476696)
Using this technique to compare the current time to engine start time would cause the exact problem described.
Re:Integer Overflow Bug in Boeing 787 Dreamliner by ambrop7 on Saturday May 02, 2015 @08:46AM (#9476857)
It would. Which would fail the condition that I mentioned "if the timing/duration of the events is suitably limited". So you should just not do what you suggest :)
Re:Integer Overflow Bug in Boeing 787 Dreamliner by ams6110 on Saturday May 02, 2015 @07:02PM (#9478898)
Isn't the actual problem using raw integers to represent time, instead of a proper date/time data type and supporting (tested) library functions?