The other one to watch out for is the 53-bit javascript integer limit. That caused the twitpocalypse when Twitter tweet IDs hit it. They had to switch to strings in the JSON representation.
Chess.com stopped working on 32bit iPads because 2^31 games have been played
181–190 of 338 posts
Re: Chess.com stopped working on 32bit iPads because 2^31 games have been played
#182Reminds me of the havoc that was caused when Twitter tweet IDs rolled over. Resulting in every third party developer to update their apps (and at the time there were a lot of those). Twitter saw it coming and forced the issue. By saying that at a certain date and time they would manually jump the ID numbers rather than wait for it to happen at some unpredictable time.
They didn't roll over, they exceeded 2^53-1 which is the max Number which doesn't truncate when treated as an integer in js. The solution was to treat it as a string. (Or we're thinking of different events, I apologize if so)
Yep, it would just point to the wrong tweet. Fun stuff. So many of these time bombs.
Re: Chess.com stopped working on 32bit iPads because 2^31 games have been played
#183Earlier quoted context omitted.
It's most likely for efficiency and performance reason. 64-bit doubles the storage requirement of 32-bit and would have impact on database's utilization of memory, querying window size, cache, and storage. Edit: 32 bits worth of games played means about 4 billion games. 4 billion X 4 bytes for 32-bit = 16GB just for the 32-bit ID's. 64-bit ID's would need 32GB for the 4 billion games. I guess memory and storage weren…
It also could've been just the person picking an int over a long. Is ints vs. longs the first place to look for optimizing efficiency/performance?
On a 32-bit system, a "long" is usually also 32 bits. On a non-Microsoft 64-bit system, a "long" is usually 64 bits. On both 32-bit and 64-bit systems (Microsoft or not), an "int" is usually 32 bits.
If the issue happened only on 32-bit iPads, but not on 64-bit iPads, the programmer probably picked a "long", not an "int". Had the programmer picked an "int", the problem would also happen on 64-bit iPads.
Re: Chess.com stopped working on 32bit iPads because 2^31 games have been played
#184Earlier quoted context omitted.
- Who among us is writing code today worried about how it will be used in 2052? The good programmers who are fortunate enough to be working on software that matters.
In my experience it's not the good systems that stick around - they're cleanly replaceable. It's the quick hacks and bodges that stick around forever.
As someone who just wrote a quick hack for a temporary problem, I agree.
It's not just the shitty programmers who do this. Sometimes we have shitty product managers who won't push back against this kind of thing. And you're forced into a creating something evil because most of the job is very good but this one time, you have to suck it up.
My response to that, though I agree with you, is that when a supervisor or PM or whoever gets on you about something you know is bad, you negotiate.
"Yes, I'll do this for now because the company needs it now. But only if you guarantee me the time (and possibly people) to do it right later."
You get agreement in an email, create the ticket and assign it to yourself as mustfix two months from now. And you shove it down their throats.
That's not an ideal place to work if you have to do that, but I have worked at those places and this is how you deal with that situation.
"Yeah, I'll give you a shit solution in 1 day right now. But only if you give me a a couple of weeks for a good solution later."
In reality, I've mostly only had to deal with this situation in startups. Mid-level and mature companies are usually open to pushing back and getting things right. But there are exceptions. Today was an exception. But that's also one of the reasons I don't really want to work at startups anymore.
Re: Chess.com stopped working on 32bit iPads because 2^31 games have been played
#185The other one to watch out for is the 53-bit javascript integer limit. That caused the twitpocalypse when Twitter tweet IDs hit it. They had to switch to strings in the JSON representation.
The 2009 Twitpocalypse concerned overflow of 31-bit precision. Twitter has not yet hit 53-bits for raw number of Tweets, in fact, they passed 32-bits in 2014 and might not have reached 33-bits, yet.
Moving to strings for Javascript was really just safety planning for the future since:
> Given the current allocation rate, they'll probably never overflow Javascript's precision nor get anywhere near the 64-bit integer space.
https://twittercommunity.com/t/discussion-for-moving-to-64-b...
Re: Chess.com stopped working on 32bit iPads because 2^31 games have been played
#186Earlier quoted context omitted.
Signed overflow is ub in C
I'm aware of that. The question was whether any practical architectures will do the "wrong" thing here.
Compilers will do the "wrong" thing. For example, gcc optimizes out the "x >= 0" check in
for (int x = 0; x >= 0; x++)
Re: Chess.com stopped working on 32bit iPads because 2^31 games have been played
#187It's fascinating... the Y2K problem never came to fruition because - arguably - of the immense effort put in behind the scenes by people who understood what might have happened if they hadn't. The end result has been that the entire class of problems is overlooked, because people see it as having been a fuss over nothing. I sometimes think it would've been better if a few things had visibly failed in January 2000.
"Wait, we spent two million dollars servicing your fleet of 100 cars in the last year, and you're complaining that none of them broke down? Why spend all that money on maintenance when they just keep running?"
Are you sue those numbers are right? That's 20k per car per year. At such a cost running the cars with no maintenance then buying new cars every break down is cheaper.
Re: Chess.com stopped working on 32bit iPads because 2^31 games have been played
#188Earlier quoted context omitted.
> Self-confidence as a programmer is when starting a new project, storing the transaction ID as a long rather than an int... uint64_t even Or a UUID as others have suggested. Technically C spec doesn't really say exactly how many bits int, long and long long should be. If you want specific sizes and your code to be somewhat portable use the specific bit sizes to make that clear. There are also types for size-like thi…
> If you want specific sizes I would go further and say you should _always_ use specific sizes, unless forced otherwise. There's no reason not to.
The reason is that anything else is using default types and you lose your safety battle in each:
int32_t x = call_returning_int();
Re: Chess.com stopped working on 32bit iPads because 2^31 games have been played
#189Reminds me of the havoc that was caused when Twitter tweet IDs rolled over. Resulting in every third party developer to update their apps (and at the time there were a lot of those). Twitter saw it coming and forced the issue. By saying that at a certain date and time they would manually jump the ID numbers rather than wait for it to happen at some unpredictable time.
They didn't roll over, they exceeded 2^53-1 which is the max Number which doesn't truncate when treated as an integer in js. The solution was to treat it as a string. (Or we're thinking of different events, I apologize if so)
Twitter must have been misleading when they communicated the reasons for this change since they did not exceed 2^53-1, nor do they expect to exceed this in the near future.
From a (former) Twitter dev:
> Given the current allocation rate, they'll probably never overflow Javascript's precision nor get anywhere near the 64-bit integer space.
https://twittercommunity.com/t/discussion-for-moving-to-64-b...
Re: Chess.com stopped working on 32bit iPads because 2^31 games have been played
#190Earlier quoted context omitted.
> If you want specific sizes I would go further and say you should _always_ use specific sizes, unless forced otherwise. There's no reason not to.
The reason is that anything else is using default types and you lose your safety battle in each: int32_t x = call_returning_int(); line. Otherwise, you assert/recover on each me-they borderline. C is a language where you have absolutely no guarantee that int or constants defined as int will fit into anything beyond int, long or long long, and then there is UB patiently waiting for your mistake. The method of handling…
This is a perfect use for the C++ auto feature:
auto x = call_returning_int();