Bug roku 2010
Kdo si myslel, že když úspěšně přežil přechod z roku 1999 na rok 2000, že teď může klidně spát minimálně do roku 2038 kdy přetečou 32 bitové unixové time_t, ten se mýlil.
Něco o tom ví italský výrobce registračních pokladen Custom Engineering. Jeho kasy přešly z roku 2009 přímo do roku 2016. Jedná se (neověřeno) o přibližně 43000 strojů. Poznámka ‚neověřeno‘ se vztahuje pouze k počtu problémových strojů. Bug samotný je ověřen, viz fotografie. Jednu takovou kasu máme v kanceláři. fotografie
S největší pravděpodobností jde o to, že RTC jede v BCD (jako ostatně drtivá většina těchto součástek), ale program tuto hodnotu interpretuje jako binární číslo. Takže RTC přešlo z 9 na 10, ale program to přečetl jako 0×10.
Problém je komplikovanější, než by se mohlo na první pohled zdát. Tyto kasy jsou vybaveny fiskální pamětí, do které se ukládají informace o uzávěrkách.
Kdo si problému všiml okamžitě, dřív než vydal první účtenku, mohl jednoduše opravit datum. Jestli to ovšem jde. Vzhledem k povaze bugu to pravděpodobně ani nepůjde. (na naší kase jsem zatím raději nic nezkoušel) Tito klienti tedy budou muset počkat na upgrade firmware.
Ti, co už udělali aspoň jednu účtenku jsou v poněkud horší situaci. Kasa nedovolí změnit datum a čas pokud se předtím neudělá uzávěrka, což je v tomto případě to nejhorší, co človek může udělat, viz další odstavec. Tito klienti budou muset nechat resetnout kasu a upgradnout firmware.
Ten, kdo už udělal uzávěrku je v nezáviděníhodné situaci. Tato situace je nezáviděníhodná především pro výrobce tohoto stroje. Kasa totiž za žádných okolností nedovolí vrátit se s datumem před předchozí uzávěrku. Něco o tom vím, protože díky bugu v mém programu jsem poslal 2 kasy do roku 2020 (v paketu na změnu datumu se měl poslat rok jenom dvoumístně, ne čtyřmístně jak jsem posílal :-) ).
V takovém případě se dá udělat jenom jedna věc. Poslat kasu výrobci a ten v ní vymění fiskální paměť. Tím ovšem starosti nekončí. Je to jako by klient koupil novou kasu (má nové číslo). V takovém případě se podle italských zákonů musí stará kasa odhlásit a přihlásit nová. Obnáší to mimo jiné i poslání doporučeného dopisu na finanční úřad.
Otázka je, jak si s tím výrobce poradí. Ono už jenom resetnutí kasy a upgrade firmware není věc, kterou by zákazník mohl udělat sám. Na to musí zavolat autorizovaného technika, kasa se odplombuje, udělá se co je potřeba, zase se zaplombuje a zapíše se o tom zápis do fiskální knihy, která je nedílnou součástí každé kasy. (Třeba jenom ztráta tohoto sešitu je záležitost, která by vydala na další článek.)
-
Juraj (neregistrovaný)
Aj spamassassin ma 2010 bug :-). http://spamassassin.apache.org/
-
jirka22 (neregistrovaný)
Tady jen někdo zapomněl na desetiletí: http://www.amit.cz/cz/faq/faq_hw.htm#problem2010
-
Radovan (neregistrovaný)
13: Zdá se že ti chybí umění porozumění psanému textu, stejně jako znalost toho co je BCD. Takže ten čip počítá v desítkové soustavě s čísly 00 až 99 uloženými v binárním kódu jako dvě čtyřbitové číslice, zatímco program to chápe jako jedno osmibitové binární číslo, které se šestnáctkově píše 0x00 až 0xFF. Rok 10 je uložen jako 0001 0000, program přečte 00010000, což je ale 16. Už to začínáš chápat?
-
mamlasek (neregistrovaný)
[14], [15]: ale jak je tedy mozne, ze pro rok 2009 (9 dec = 1001 bin) se to chovalo spravne, kdyz bylo cislo ulozeno jako "0000 1001". a nyni, kdyz je ulozeno "0001 0000" uz se to vyhodnocuje jako hex?
samozrejme do pokladen nedelam :D ... jen me zajima, jak vubec muze dojit k tomu, ze jeden rok (respektive 9 let) je to OK, a dalsi rok uz se cislo vyhodnocuje uplne jinak...
teda vlastne me napada jedine - uz od zacatku to bylo navrzene spatne, a cisla se vyhodnocovala jako sestnactkova, a prislo se na to az ted... ? (snad nepapouskuju neco z clanku)
-
Radovan (neregistrovaný)
[16] Tak ještě jednou to BCD: 0000 1001 je binárně zapsané desítkové dvojčíslí (Binary Coded Decimal) 09 a 00001001 je binární číslo 9. Obě mají stejnou podobu, což ale platí jen pro čísla 0 až 9. Zrada je v tom, že dalších šest hodnot 0xA až 0xF se v BCD nevyužívá, takže 0001 0000 v BCD znamená teprve 10, zatímco binárně 00010000 je už 16! A s každou další desítkou se ten rozdíl ještě zvětší, z celkových 256 možností které dává jeden byte se v BCD využije jen 100...
Ano, vypadá to že je to od počátku špatně navržené, a že tuhle možnost prostě nikoho nenapadlo ani odzkoušet, natož v programu ošetřit. Také to mohlo vzniknout tím, že někdo nepochopil nebo nepřečetl datasheet toho hodinového čipu a prostě si myslel že funguje jinak než tomu ve skutečnosti je.
Pro podrobnější popis BCD mrkni sem, sem, nebo do nějaké učebnice, není to jen otázka pokladen ale spousty dalších zařízení a programování jako takového, je to o číselných soustavách a různých kódováních čísel, kterých se v historii používaly desítky a dodnes jich pár přetrvává.BIN BCD HEX DEC OCT
00000111 07 0x07 7 07
00001000 08 0x08 8 10
00001001 09 0x09 9 11
00001010 -- 0x0A 10 12
00001011 -- 0x0B 11 13
00001100 -- 0x0C 12 14
00001101 -- 0x0D 13 15
00001110 -- 0x0E 14 16
00001111 -- 0x0F 15 17
00010000 10 0x10 16 20
00010001 11 0x11 17 21
00010010 12 0x12 18 22
Josef Pavlík
Poslední názory
-
\
Dekuji vsem diskutujicim za podmente pripominky
ke článku Počítání s přetečením v C -
\
jj já vím, ten komentář jsem napsal proto
ke článku Počítání s přetečením v C -
\
Ovsem v mem pripade potrebuji pocitat na 65 bitu, takze 64+carry
ke článku Počítání s přetečením v C -
\
Saturated neimplikuje nemožnost použít dvojkový doplněk a zrovna
ke článku Počítání s přetečením v C -
\
Saturace je něco naprosto jiného
ke článku Počítání s přetečením v C
