5 ms·
I learned about this yesterday from a Tom Scott video (https://www.youtube.com/watch?v=MVI87HzfskQ https://www.youtube.com/watch?v=MVI87HzfskQ). I find it odd
by fpgaminer 11y ago
I learned about this yesterday from a Tom Scott video (https://www.youtube.com/watch?v=MVI87HzfskQ 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.
- OliverJones 11y agoI wonder what happens if one sets the iOS clock forward to noon on Jan 19, 2038? (at 03:14:08 UTC on Jan 19 2038 the 32-bit signed time_t flips over).
- Elv13 11y agoWell, if they use 32bit time_t: Exactly the same is this bug. If they use 64bit time_t: Nothing unusual for the next 4 billion years or so until the sun explode.
- madaxe_again 11y agoTsch, such obvious planned obsolescence, trying to force us into a mere gigayear scale upgrade cycle.
- valarauca1 11y agoAt least after the 128bit switch I know that proton decay will be the next thing I need to worry about.
- simonh 11y agoIntroducing 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.
- TazeTSchnitzel 11y agoEven on 32-bit devices, all is fine. SSL certs don't validate, though, but that's merely because the date is wrong, not because it's a specific date.
- Animats 11y agoUnderflow occurs because applying the time zone offset to a time of zero can generate a negative time. UNIX time is UTC internally.
- kuschku 11y agoThat explains why it only happens in the US, but not Europe.
- thought_alarm 11y agoAll 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.
- the_mitsuhiko 11y ago> 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.
- userbinator 11y agoI 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.
- the_mitsuhiko 11y agoIf 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.
- 13of40 11y agoYou 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.
- toxik 11y agotime() actually returns a pointer, so your point is NULL.
- fpgaminer 11y agoPOSIX `time` returns time_t. Not sure what `time` function would return a pointer?