Slashdot Mirror
Chess.com Has Stopped Working On 32bit iPads After the Site Hit 2^31 Game Sessions (chess.com)
Apple's decision to go all in on 64bit-capable devices, OS and apps has caused some trouble for Chess.com, a popular online website where people go to play chess. Users with a 32bit iPad are unable to play games on the website, according to numerous complaints posted over the weekend and on Monday. Erik, the CEO of Chess.com said in a statement, "Thanks for noticing. Obviously this is embarrassing and I'm sorry about it. As a non-developer I can't really explain how or why this happened, but I can say that we do our best and are sorry when that falls short." Hours later, he had an explanation: The reason that some iOS devices are unable to connect to live chess games is because of a limit in 32bit devices which cannot handle gameIDs above 2,147,483,647. So, literally, once we hit more than 2 billion games, older iOS devices fail to interpret that number! This was obviously an unforeseen bug that was nearly impossible to anticipate and we apologize for the frustration. We are currently working on a fix and should have it resolved within 48 hours.
This was obviously an unforeseen bug that was nearly impossible to anticipate
Only if you're an idiot.
Watch this Heartland Institute video
The problem could waited twice longer — giving the 32bit iPads time to break down and die of old age on their own — but somebody wasted an entire bit for the possibility to return -1 somewhere...
Any time you pick ssize_t over size_t, for example, you are making the same decision...
In Soviet Washington the swamp drains you.
I'm not Apple apologist, but come on why point the finger at Apple? This would have happened on any 32-bit architecture. Blame the devs of the game for not knowing how this works, not Apple.
Everyone please stop using int and long intrinsic types. uint64_t is your friend when you expect so many games. 2^31 tells me it wasn't even unsigned. How could there be a negative number of games played?
Yeesh.
Mission: To provide products that consume time and energy as entertainingly as permitted by the laws of thermodynamics.
How do you know it isn't the Russians?
I am not sure how Apple going 64bit is the one causing the problems? This particular problem (and most others caused by the discrepancy) would still be a problem if Apple devices were all still 32bit... It would only have been a much bigger problem than it is now.
Just don't use numeric values for your primary key if you plan on growing.
That's like saying 8-bit processors can't handle (signed) numbers above 128. The processors handle them fine. The programmers on the other hand...
If you visit my website with IE6 good luck - ancient device not so good experience. If you own iDevice you are supposed to replace it every other year - that is in the contract:)
Wait.... what? First of all.... you can get TWICE that by using an "unsigned" 32-bit.... since there should never be a negative game ID.
And also what 32-bit machine doesn't have register-combining for 64-bit variables? Just because it isn't representable in a signed 32-bit integer does NOT mean it's 32-bit incompatible...
This explanation makes absolutely no sense to me.
Someone used an int type somewhere in the code whose size is architecture specific. There's no reason a 32-bit iPad couldn't support 64-bit numbers.
... yes. See the data types directly hardware-supported on the 80386 for example, it supported 64 bit numbers in hardware, and your compiler can emulate that in software if the hardware doesn't directly support it.
https://en.wikipedia.org/wiki/...
It's extremely common for CPUs to support a word size double their "bits", e.g. 8 bit machines generally had a 16-bit integer type, used for addressing 64K of memory.
I typed "2,147,483,647 + 1" into my old iPad calculator app and it said 2,147,483,648!
I'm not a programmer, but maybe the answer is to just rewrite your website to use the iPad calculator?!
I hear Apple have sold like, 1 billion of them or something, so you'll be able to use it a billion times two billion at least!
I am currently working on a web site backed by a MySQL data base. The main table has a must-be-unique ID field which is typed as a Java Long object. So my data base is going to break when it hits 2^63 records. Should I be worried?
You with your reasoned discussion. Knock that off!
Pretty sure you're thinking of this, but I wouldn't be surprised if it was something else. https://slashdot.org/story/06/...
There is no XUL, only WebExtensions...
Apple's decision to go all in on 64bit-capable devices, OS and apps has caused some trouble for Chess.com, a popular online website where people go to play chess.
Apple's "64-bit only" decision has nothing to do with this.
systemd is Roko's Basilisk.
So according to this article, Apple going to 64 bit is making this site fail. What a ridiculous nonsense.
1. Apple hasn't changed everything to 64 bit yet. iOS 11 will only run on 64 bit systems and won't run on any device that is 32 bit only, but this hasn't happened yet.
2. 64 bit applications work just fine. Apparently the application uses 32 bit in the 32 bit version and 64 bit in the 64 bit version, the 32 bit version overflows and the 64 bit version doesn't. So if Apple had killed off all 32 bit versions, which they didn't, everything would have actually been fine.
3. The problem is not 32 bit vs 64 bit application, it is using a 32 bit counter for a quantity that exceeds 32 bits. But 32 bit applications can easily use 64 bit counters. They are just a tiny tiny bit slower, but work just fine.
So the problem has nothing to do with Apple, it is using a 32 bit variable for a 64 bit quantity, in other words, an elementary programming error by the application developer.
If only there were some way of coping with numbers greater than 32 bits long on a 32 bit engine.
There's almost no reason to use "long". The only non-bogus things I can think of from the top of my head are memcpy implementation, bitwise operations and similar things on a block of memory when you want to handle a word at a time -- where doing it byte-by-byte would work just as well, merely slower.
Either your program needs to handle values >= 2^31/2^32, or it doesn't. In the first case, you use [u]int64_t, in the latter it should be int. Anything else introduces a pointless portability problem: int works as fast if not faster on 64-bit than long, too (at the very least by taking fewer cache lines when stored in memory).
As for values that deal with structure sizes, there's [s]size_t/[u]intptr_t.
The only nasty thing is printf() -- when using arch-independent types, you need that ugly %" PRId64 " stuff. It even breaks in C++ where some bright person had the idea to break compat and require a space after the " -- and your C code may be included into C++ when you don't expect.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
In general the advertised word size of a processor is the data size of the general purpose registers and the largest data size that most regular instructions can work on.
The one reasonablly common exception to this is the results of multiplications. Many processors with hardware multipliers have a multiply instruction where the result is double the size of the arguments and stored into two registers.
Larger additions/subtractions/comparisions can be performed by using a carry flag. Larger multiplications can be performed by a variant of long multiplication. There are ways to do larger divisions too though they get quite copmlex.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
This is what happens when a bunch of smart chess players pretend to be mathematicians and programmers
Sent from my TARDIS
This website started in 2005, so unless they saw Nokia brick phones as the way of the future, I really doubt they thought they'd get anywhere close to that many games.
You mean to say they expected to fail before 2 billion games had been played?
Matter of fact, you can blame all (32 and 64) smart phones for this because no one ever seems to close out of their apps.
Why? Does the app continuously play games by itself if you leave it open, thereby artificially inflating the number of games played? No, I don't think it does. And we're talking about the number of games played, ever, not the number of games currently being played, or the number of app instances currently open. Whether people close out their apps or not has absolutely nothing to do with this.
The popular consensus is that most of chess playing traffic comes from old-school Linux users anyway.
Right. So are you saying that their games don't count toward the total number of games played? Because that's what got pushed over 2 billion.
They could just have games close and delete automatically after a period of time.
They could, sure. But, unless they want to deal with data integrity issues, the IDs would continue growing, and it's the ID being too high that is causing the problem. Well, I misspoke there, it's too small of an INT type being used that caused the problem, but that INT is storing the game ID, so it was the ID being too high that revealed the problem.
And, two billion people are never going to be on Chess.com at the same time.
Of course not, but two billion games will eventually have been played, as evident by the fact that this has happened.
But let's say they are, then just use multiple servers.
And the same number of games would have been played, still.
Don't blame the bits for this because the main audience is upgrading anytime soon.
I don't think anybody (except the developer) did this, actually. The fault lies squarely with the developer who used an architecture-dependent INT type rather than forcing a 64-bit INT.
Just keep showing me how much you don't know about things, Hayden. Oh, and good luck in August; let me know if you need a ride.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
A succint summary of issue and resolution. I'd hire you.
He not only lacks technical skills he clearly not even competent as a CEO because he missed the golden opportunity to highlight the success of chess.com: "We did not anticipate the huge popularity of chess.com which caused us to exceed two billion chess games which were more games than some of the code could handle. We apologise for the oversight and will be issuing a patch which will let us grow to 2^63, or over 9 quintillion games.".
Failing because you did not anticipate being a huge success makes you look a lot better than just failing because you think it is impossible to foresee overflowing an integer variable.
How, exactly, is this Apple's fault? This is a developer programming error based on a lack of understanding how to represent large numbers on systems with limited WORD sizes. Even on the ancient 6502 or Z80 (8 bit processors), we knew how to write code that could handle numbers that far exceed 2^31. And, before they start talking about performance, I need to ask, how many frames per second do you need to render a chess game?
The developers need to place the blame with themselves where it belongs.
I suppose they could, but all played games are preserved in their entirety. Not doing so would be considered a much bigger error in judgment.
It's propably declared as 'Int' which takes the size of the platform is runs on, so on a 32bit platform it will be 32bit, on a 64bit platform it will be 64bit, and so on.. Personally I don't like declarations like that, always just declare it as what you want it to be (int32, int64 or uint32 if you're not gonna go negative, which would have worked in this case too).
Who says they used an architecture dependent int type. They very well may have declared an int64 and then, when they ported to 64-bit, changed it to int128 but never merged the change back to the 32-bit branch. Not everybody has one branch that builds for 32 and 64-bit. Often the 64-bit transition is considered "one way" and the 32-bit branch isn't maintained.
Who says they used an architecture dependent int type. They very well may have declared an int64 and then, when they ported to 64-bit, changed it to int128 but never merged the change back to the 32-bit branch.
Just saying that it seems that's what they did; and the numbers at play here overflow a signed int32, not a signed int64, so you're wrong either way.
Not everybody has one branch that builds for 32 and 64-bit. Often the 64-bit transition is considered "one way" and the 32-bit branch isn't maintained.
The only valid reason to do that is if you're relying on an external, binary-only library that is no longer seeing updates from its vendor. I would have said the use of assembler might be a valid reason, but I also recently learned that (at least a handful of) modern C compilers will also compile assembler and can even replace 64-bit instructions with 32-bit routines on the fly, so you can even compile 64-bit assembler for a 32-bit platform now.
Might not run as fast, since you're expanding single instructions into entire routines, but it shouldn't be any slower than native 32-bit assembler, either, given that you'd have had to write similar routines in the first place. If anything, it should be a smidge faster what what you'd have written yourself, given that the compiler author would likely have optimized the routines used, as compilers primarily compete on performance.
But, all of that is irrelevant when we're talking about an iOS app, where Apple takes an intermediate representation of your app and compiles it for both 32-bit and 64-bit architectures on their end; and they won't accept apps that don't compile correctly, for hopefully obvious reasons. If you don't provide bitcode (either because you're using some library for which bitcode is still not available, or for whatever other reason), Apple still requires a fat binary for anything targeting iOS 5.1.1 or newer; anything older than that is 32-bit only anyway.
It's basically dictated by Apple that you use a single branch for 32- and 64-bit, so it's not just a safe assumption, but an absolute truth, that the app in question was developed that way.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Nope.
With macOS C compilers, int is always 32 bits. long can be 32 or 64 bits and the Cocoa integer type (NSInteger) can also be 32 or 64 bits.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
It all depends on the language and as you say compiler. but who says this app was written in C? it's an iOS app, so I doubt it. It's more likely to be written in cocoa where as you put it correctly int can be 32bit or 64bit.
But i have no idea, as you cannot develop on windows for iOS (at least not compile and distribute).
The article mentions that on older 32bit iOS devices, games don't run because they can't count that high. Understandable. One would presume that this is also the case on *any* 32bit system, not just iOS.
And what's with the lede?
What?!? Moving to 64bit means newer devices *won't* have that problem on chess.com or any other site or app that uses very large integers, so I fail to see how this is Apple's doing, or is even related to Apple at all (aside from the problem first being discovered on an old iPad). Just another way to get Apple into the headlines?