I learned about this yesterday from a Tom Scott video (https://www.youtube.com/watch?v=MVI87HzfskQ). I find it odd that his sources are suggesting that this is an integer underflow bug. First, while integer underflow itself would be a bug in this case (if it's occurring) the real bug would be not handling large time values. If they are indeed using u64 to store time, the system should be designed to, you know, handle u64. Why would parts of the system break for values like 0xFFFFFFFFFFFFFFFF?
Second, and this is more important, iOS likely is _not_ using u64. It's a BSD derivative, so it's using time_t, which is signed. No underflow involved. It just literally goes negative. And this is far more likely to be the cause of the issue. In POSIX systems, many time fetching functions return -1 as an error code, and I can easily see some programmer doing `if ((t = time(NULL)) < 0) { halt_and_catch_fire(); }` or `while (time(NULL) < 0); // wait for RTC to start up`. That's more likely, in my opinion, than some part of iOS using u64 for time and not handling large values.
The take away? My fellow engineers, please stick with time specific types (like time_t) that are i64 underneath, and please don't return negative values as error codes. Wrap broken functions like `time` into functions that return the time and an error code separately. If you'll recall from those history classes in high school and college, time before 1970 was fairly important (though clearly not as exciting without iPhones), so it's worth representing.
All we know is that boot-up fails on 64-bit hardware. We don't have nearly enough information to accurately guess which boot-time component is failing or what API this component is using.
A trivial example would be casting an `unsigned int` to a `time_t` (i.e., `long`). It will work with negative numbers on 32-bit systems, but will fail with negative numbers on 64-bit systems.
Introducing the iPhone 7. It's the first iPhone specifically engineered to withstand the Sun exploding in 7 billion years' time, and we think you're going to love it.
> In POSIX systems, many time fetching functions return -1 as an error code, and I can easily see some programmer doing […]
Particular in this case which traditionally is a function which does not indicate failure by setting `errno`. On many systems it's impossible to distinguish a second before epoch with a legitimate failure.
I think of this another way: why should a "get current time" function ever return an error? And what is someone to do about that case anyway? The time it returns may be wrong, but I think such a function shouldn't be capable of returning "error", as adding that path just increases complexity needlessly without much additional benefit; with the current time being used often in things like error logging, introducing an "error on top of an error" is not a good idea. Defaulting to January 1, 1970 or December 31, 1969 would be sufficient.
If you look into the glibc sources you will find time() implemented as always returning -1. Not all systems have a clock. So specifically for linux for instance it will ask the os for the time.
You know, the sad thing is even though I fall into the set of folks who "don't need that video", I can't figure out how to set the year on my iPad's date.
Second, and this is more important, iOS likely is _not_ using u64. It's a BSD derivative, so it's using time_t, which is signed. No underflow involved. It just literally goes negative. And this is far more likely to be the cause of the issue. In POSIX systems, many time fetching functions return -1 as an error code, and I can easily see some programmer doing `if ((t = time(NULL)) < 0) { halt_and_catch_fire(); }` or `while (time(NULL) < 0); // wait for RTC to start up`. That's more likely, in my opinion, than some part of iOS using u64 for time and not handling large values.
The take away? My fellow engineers, please stick with time specific types (like time_t) that are i64 underneath, and please don't return negative values as error codes. Wrap broken functions like `time` into functions that return the time and an error code separately. If you'll recall from those history classes in high school and college, time before 1970 was fairly important (though clearly not as exciting without iPhones), so it's worth representing.