Názory k článku
Problém 2^31: Chess.com nefunguje na starších 32bitových iPadech
-
Ondra Satai NekolaZlatý podporovatel"Apple svým rozhodnutím přejít na 64bitové aplikace a operační systém způsobil problém na Chess.com"
V tomhle bude nejspíš Apple nevinně.
-
ZrzkaStříbrný podporovatelNejspis? Je v tom nevinne a zariznuti 32-bitovych appek s tim nema vubec nic spolecneho. Bulvarni titulek, nic vic.
-
FíkZlatý podporovatelTak jestli to chápu dobře, tak ta Chess.com appka je duální, tedy jak 32 tak 64 bit. Apple už víc jak rok tvrdí, že letos 32bit zařízne, tedy vývojáři na to už trochu kašlou. Proč udržovat něco, co brzo zaříznou?
Přes web to prý jelo pořád. Problém je v té 32bit části appky.
-
Tak tak. Datový typ uint64_t můžu používat i na osmibitu.
V dobře napsané aplikaci by stačilo dostatečně dlouho předem (po překročení 3 mld. her) změnit jeden řádek, v C++ by to bylo nějak takhle:
typedef uint32_t matchId;
na
typedef uint64_t matchId;
a updatovat appku. Takže nevím, v čem je problém u Apple, když to pokakal někdo jiný. -
LukyH (neregistrovaný)
Neznamenkový 32-bit typ může uchovávat číselné hodnoty od 0 do cca 4 miliard (resp 2^32) což by bylo ideální pro uchování ID. Buď tedy programátoři aplikace zvolili pohodlně typ int nebo je ve výběru omezoval použitý programovací jazyk, např. java nemá neznamenkové typy. Takže jako workaround by se mohl použít ten první typedef pokud to bylo v C/C++ ;-). A emulace (jestli to tak říkám správně) typu s bitovou šířkou větší než umožňuje procesor byla vždy pekelně zaplacena výkonem výsledné aplikace. Nevím kolik by to na 8-bitu stálo, pamětnící jistě odpoví lépe :-)
-
j (neregistrovaný)
2LukyH: Nemuze, to je stadecko mistnich fuckkbookovych debilu, ktery nicemu nerozumej, o vsem vedi hovno, a sere je, kdyz nekdo o necem neco vi.
Jinak je to typicka ukazka programovani patlalem (takovych co propagujou ze prece programator nemusi vedet nic tu je taky hromada), kterej vi lautr hovno o tom, co z toho jeho kodu vyleze. Protoze to, ze trebas int je ka kazdy platforme jinak velkej (a dokonce jeste muze mit big/little endian reprezentaci) vedelo za mych casu i 10lety decko. Proto se trebas misto toho intu velmi casto pouzival char.
-
. . (neregistrovaný)
člověk je vždycky chytrej, když netuší, co ten program dělá. Pro ipad se píše v určité derivaci object C (Cocoa, Swift atd.).
Pravděpodobně použili NSNumber, který má velikost podle platformy, uint64_t k dispozici je. Je otázka ale co s tím číslem vše dělají, jestli ho generují či jinak s ním pracují a kam ho předávají, svět nemusí být jednobarevný.
Aplikace je několik let stará, pro uložení čísla použili nejspíš tu nejjednodušší cestu, tomu nasvědčuje i rychlost opravy.
-
ZrzkaStříbrný podporovatel
Trochu to poupravím ... ipad je iPad. object C neexistuje, je to Objective-C (ObjC). Cocoa jsou v podstatě tři frameworky - Foundation, AppKit a CoreData. No, je tam toho víc, ale to není podstatné. Swift je nový jazyk představený Applem a trochu postrádá smysl ho uvádět v závorce s Cocoa.
NSNumber nemá velikost podle platformy. NSNumber má velikost jakou chce vývojář. Záleží jenom na tom co do něj uložíte, viz. https://developer.apple.com/documentation/foundation/nsnumber
Spíš někdo použil NSInteger / NSUInteger https://developer.apple.com/documentation/objectivec/nsinteger?preferredLanguage=occ, který to tak opravdu má: When building 32-bit applications, NSInteger is a 32-bit integer. A 64-bit application treats NSInteger as a 64-bit integer.
Prostě klasika, lidi zapnou 64-bit a nemají vůbec tušení co se pod tím děje. Obdoba toho když jsem někomu na SO vysvětloval, proč se mu BOOL na 64-bit chová (podle jeho slov) divně :) https://stackoverflow.com/questions/31267325/bool-with-64-bit-on-ios/31270249#31270249
-
Pako (neregistrovaný)
"Apple svým rozhodnutím přejít na 64bitové aplikace a operační systém způsobil problém na Chess.com."
Toto není pravda, s žádným "přechodem na 64bitové aplikace" chyba nesouvisí. Souvisí s chybným odhadem potřebné "kapacity" proměnné pro identifikátor hry. Pokud by aplikace zůstaly 32bitové, nastala by také.
Aplikace je na 99% napsaná (tak jako drtivá většina starších aplikací) v Objective-C, a proměnná je velmi pravděpodobně typu NSInteger: https://developer.apple.com/documentation/objectivec/nsinteger?preferredLanguage=occ
-
FíkZlatý podporovatel
Tak souvisí, NSInteger má na 32bit nedostatečnou délku, ale na 64bit už dostatečnou. Vývojáři měli všichni už 64bit zařízení, takže ani chybu nemohli zezačátku reprodukovat.
Když by Apple zůstal jen 32bit, třeba by si toho všimli a opravili.
-
FíkZlatý podporovatel
To není můj blábol, pouze jsem to převzal ze slashdotu, kde to mimochodem stále je.
A další blábol je zase z prohlášení na Chess.com: "Early reports from members were difficult to understand. They were also impossible for us to reproduce since most of us are on newer 64-bit devices. (Doh!)"
Já myslím, že je teď už jasné, co se vlastně stalo. Apple za to nemůže, ale souvislost tam je.
-
Kdybych chtěl číst zprávičky ze Slashdotu, tak chodím na /. Od Root.cz očekávám nějakou novinářskou práci v článcích i ve zprávičkách.
Hlavní důvod, proč jsem neobnovil (zlatou) podporu pro Root.cz i na další rok, bylo to, že mne tenhle lajdácký přístup ke zdrojům (obecně, nikoli jen u Vás konkrétně) rozčiloval mnohem více než teď, když jsem zase jen řadový čtenář.
-
FíkZlatý podporovatel
tak konkrétně v tomto případě k tomu bylo zpočátku málo zdrojů a všechny v podstatě říkaly to stejné
jak se objevilo oficiální prohlášení na Chess.com, tak jsem to sem do hodiny od jejich zveřejnění přidal
-
ZrzkaStříbrný podporovatel
Koukám, že si nenecháte nic vysvětlit.
Apple se rozhodl, že počínaje iOS 11 bude podporovat pouze 64-bit. To má za následek to, že iOS 11 nebude podporovat starší zařízení (32-bit CPU) a nebude možné spouštět 32-bitové aplikace na iOS 11 (už od dob 10.3 vyskakuje varování The developer of this app needs to update it improve its compatibility v případě, že je aplikace jen 32-bit).
Vývojáři se sami rozhodli, že budou podporovat 32-bit a zároveň 64-bit. 32-bit pro starší verze iOS, resp. pro starší zařízení s 32-bitový chipem (iPhone < 5S && iPad < Air). No a prostě a jednoduše zvolili špatný datový typ -> integer overflow.
Když by Apple zůstal jen 32bit, třeba by si toho všimli a opravili.
Jenže Apple nepřechází z 32-bit na 64-bit teď. 64-bit je tu s námi už přes dva roky a od 2015 je povinnost nahrávat do App Store minimálně 64-bit verzi aplikace. Běžně se tam nahrávali & nahrávají obě verze, resp. arm64, armv7, armv7s.
Apple pouze oznámil, že s 32-bit u iOS 11 končí. A i kdyby to nakrásno neudělal, tak ten problém mají vývojaři i tak. Pořád budou mít na starších zařízeních integer overflow -> nesouvisí to s tím.
-
FíkZlatý podporovatel
Ano, chyba ve 32bit by tam byla i tak. Když ale vývojáři používali jen 64bit verzi bez chyby, jak si jí měli všimnout? Asi jde o věc názoru a pohledu jestli to souvisí nebo ne.
-
ZrzkaStříbrný podporovatel
Když ale vývojáři používali jen 64bit verzi bez chyby, jak si jí měli všimnout?
Pokud vytvářím aplikaci, která podporuje i 32-bit, testuju ji i na 32-bit zařízení. Pokud to nedělám, tak podporu pro 32-bit vypnu. Když to neudělám, jsem vůl a můžu si za to sám. Nejde o věc názoru, prostě to s tím nesouvisí.
-
KateStříbrný podporovatel
Pro Apple nevyvíjím, ale oni v rámci svého IDE nemají aspoň virtuální běhové prostředí, jako to má Android? Protože pak by bylo to diletanství ještě o něco markantnější. :)
-
KateStříbrný podporovatel
Navíc vlastně mohli zkompilovat čistě 32bit neuniverzální verzi a testovat to klidně na svých 64 bitových zařízeních dokud to Apple dovoluje, dopadlo by to stejně.
-
FíkZlatý podporovatel
Podle mě to stejně souvisí, ale jsem asi v menšině, tak jsem zprávičku opravil.
-
Petr M (neregistrovaný)
Takže ono je vlastně normální, že někdo vydá dvě binárky, každou pro jinou platformu, a tu jednu ani nezkusí spustit? A ještě hází vinu na okolí, když se zjistí, že ta netestovaná binárka nefunguje?
- Když nedokážou 32b otestovat, měli by to zaříznout.
- Když to nechtějí zaříznout, měli by si sehnat starší 32b zařízení a jednoho člověka, co se tomu pověnuje.
- Když nechtějí vyhodit 32b a nechtějí testovat 32b, musí čekat ostudu, to je jenom otázka času. A pak jde jenom o to, jestli to hnědý mazlavý budou házet kolem sebe, nebo si to uklidí a omluví se.Jiná možnost tady není.
-
FíkZlatý podporovatel
Chess.com to na Apple neházel, to někdo jiný dal do souvislosti s nedávným oznámením zaříznout 32bit v iOS 11.
-
KateStříbrný podporovatel
Tyjo, to zkusím použít až způsobím v práci nějaký brutální bug. „Testovala jsem to na svém Archu s novými verzemi knhoven, jak jsem si teda měla všimnout, že to bude na debianích serverech blbnout?“
Pokud to má v nějakém prostředí běhat, tak to v tom prostředí taky testuju. Pokud vydají zabugovanou Android verzi, bude taky validní výmluva ža mají jen iPady a do zprávičky napíšu že „svým rozhodnutím nebýt Applem Google způsobil problém na Chess.com“?
-
KateStříbrný podporovatel
Na stranu druhou, dobře napsaný unit test by měl řešit všechny eventuality. Předpokládám že tady šlo o načtení ID ze serveru přes api. Takže jako ID be se mělo testovat třeba i pole, "mrkev", záporné číslo, maximální možné číslo ID…
-
Karel (neregistrovaný)
Ne, Unit test, pokud je správně napsaný, vám tohle neodhalí. Ten vám jen řekne, jak se aplikace chová, když přijde přetečená hodnota. Že na nějakém serveru právě teď přetekla hodnota, to Unit test neví. To má být ošetřeno v aplikaci od začátku - server nemá takovou hodnotu vůbec generovat.
Co se používá v ERP systémech je systém včasného varování. Převedeno na tenhle případ: jakmile ID hry přesáhne 2^30, tak by to mělo začít spamovat logy (na serveru) s tím, že počitadlo brzo překročí přípustnou mez. Vývojář a správce tak mají čas na řešení - buď upraví program, nebo třebas jen zresetují počitadlo. Ty úpravy bývají všelijaké. Co jsem viděl tak například:
- místo generování nekonečné sekvence se hledá nepoužitá hodnota
- změní se typ z čísla na text a použije se například BASE32
- hodnota se sváže s nějakým dalším sloupcem, takže kupříkladu místo primárního klíče "číslo objednávky" máte klíč "typ objednávky, číslo objednávky" - a pak můžete pro každý typ mít vlastní sekvenci
- nějaká kombinace s resetem počitadla - například smazání starých záznamů 1 až 999999, reset počitadla na 1 a úprava generátoru, aby od 900000 hlásil vyčerpání sekvence a u 999999 se zastavil. Na což bude reakce smazání záznamů 1000000 až 1999999, které v to době už budou také zastaralé -
KateStříbrný podporovatel
Přetekla proměnná ID hry jen na 32 bitových zařízeních. Ne na serveru. 64 bitová verze fungovala dobře.
Tudíž, server umí ID v rozsahu 64 bitového intu, 32 bitová zařízení jen v rozsahu 32 bit intu. Pokud v unit testu zkusím použít maximální možné ID zaslané serverem, chybu samozřejmě při testování 32 bitového buildu odhalím.
-
Petr M (neregistrovaný)
Ale server jede na 64b, tam není důvod cokoliv řešit. Všechno je v aplikaci. Pokud to server předává v textové formě (např. JSON), tak není problém. Když to předá 64b appce, není problém. 32b appka přeteče. S textovým mezistupněm ani nevyskočí hláška kompilátoru.
U aplikace MUSÍ projít unit testy VŠECH sestavení. A měli hned tři příležitosti, kdy přidat test, co by odhalil nekorektní chování - v okamžiku rozšíření serveru na 64b, v okamžiku, kdy appku překlápěli na 64b a v okamžiku, kdy se čítač dostal na 75% rozsahu.
Best practice je
- Generovat pro každý logický typ dat jejich vlastní typ (od toho je typedef apod.)
- Nikdy, ani při odvozování typu nebo ve strukturách, nepoužívat typy s neuvedenou délkou.
- Nikdy neignorovat warningyAle oni amatéři, co se nesetkali s pointerem, typem, alokací paměti a typová kontrola je pro ně sprostým slovem, na tohle moc nemyslí.
-
KateStříbrný podporovatel
Asi tak. Zvlášť vstup aplikace z API a vlastně jakýkoliv interface je potřeba testovat, testovat, testovat.
