"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
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ář.
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.
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í.
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í.
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“?
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é
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.
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 warningy
Ale 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í.