2016 Bug Hits Text Messages, Payment Processing 340
An anonymous reader writes "It seems some systems are suffering from a Y2K16 bug. When 2009 ticked over to 2010, some Australian EFTPOS machines skipped to the year 2016. Coincidentally, some Windows Mobile users are also having issues with their new year SMSes coming from 2016. What function could cause this kind of error?"
Microsoft (Score:5, Informative)
Seems Microsoft is supplying some code [microsoft.com] for EFTPOS machines that is common with Windows Mobile, so it's most likely the same bug in both.
10 hex is 16 decimal (Score:5, Informative)
Could be botched string parsing. Could be binary coded decimals interpreted as binary numbers: BCD encodes two decimal digits in the high and low nibbles of a byte. Therefore BCD 10 is 0001 0000 in binary, which is 16 in decimal.
Re:Some kind of... (Score:1, Informative)
I think you mean hexadecimal. When 10 is interpreted as binary, it's 3 not 16.
Re:Some kind of... (Score:5, Informative)
I don't think you quite have the hang of binary (10 would be 2, not 3).
Re:10 hex is 16 decimal (Score:5, Informative)
Re:Some kind of... (Score:1, Informative)
he meant binary coded decimal you clod
Re:Some kind of... (Score:3, Informative)
Re:Some kind of... (Score:5, Informative)
I used 0x10 because that's standard ANSI C (and ECMA-334 C#), and C is what seems to be spoken on
Re:Microsoft (Score:4, Informative)
Yes they do [google.com] (almost in every atm actually).
Re:Some kind of... (Score:5, Informative)
Let me see if I can straighten it out, then.
0x10 is a hexadecimal number, 0001 0000 binary, 16 decimal.
0x10 is a BCD number, 0001 0000 binary, 10 decimal.
(BCD is an encoding system, not a base system. In hex or binary it’s given in encoded form, but in decimal it’s given in decoded form.)
Re:10 hex is 16 decimal (Score:5, Informative)
The specification for the SMS message format pre-dates Y2K by about 15 years. I came across it in 1995 (and thought it was useless - what sort of idiot would try to fit a message into 160 characters? And who would want to type it on a 12-button keyboard?). Where I worked, nobody worried about Y2K until about 1998.
Re:Some kind of... (Score:4, Informative)
0x10 means 0001 0000.
0001 0000, if that's a binary number, means decimal 16
0001 0000, if that's binary coded decimal (BCD), i.e. decimal 0-9 represented as 0000 to 1001, means decimal 10.
(If 0001 0000 was little endian (with 4-bit groupings) it would mean binary 1)
1234 in binary (4D2 in hexadecimal) is 0000 0100 1110 0010
1234 in BCD is 0001 0010 0011 0100
Re:10 hex is 16 decimal (Score:3, Informative)
It makes a lot more sense in little endian.
Re:Some kind of... (Score:1, Informative)
Give him a break. This whole thread is made of such epic fail that it could only be unforged in Mount Doom.
10 is 3 in binary indeed...
Let's try this again.
In binary...
Binary 00 = Decimal 0
Binary 01 = Decimal 1
Binary 10 = Decimal 2
Binary 11 = Decimal 3
BCD is something different. But you said binary. And by the way, I'm not aware of any BCD format [wikipedia.org] in which 10 = 3.
Re:WHY DO PEOPLE INSIST UPON REPLACING THE FIRST Z (Score:1, Informative)
no that's a Y210 bug (Score:4, Informative)
Y bugs are named for the year in which they occur, not the year they jump....otherwise Y2K would have been Y1.9K, or even better YMCM
Re:* points finger at Duct Tape Programmers (Score:3, Informative)
It is just that I do also think the type of error the 2016 bug is can indeed be attributed to the "duct tape programming" attitude.
But that's exactly what Jamie *isn't* talking about. He never said anything about not designing the system, or doing the design ad-hoc, all he's saying is two things:
1) If your code is too complex, uses too many obscure language features, or has a structure that can't easily fit in the average person's head, it's likely to be more buggy since some of your team will never fully understand it. (Or, if they do now, future maintainers may not.) Basically, the coding equivalent to Keep It Simple, Stupid.
2) The number one feature of any application is "it shipped." It doesn't matter how great your program is if it's vaporware.
Neither of those two points have anything at all to do with this bug.
The word "duct-tape" leads people to think that the philosophy has something to do with coding by the seat of your pants. "Oh this function isn't designed right, I'll just put a couple globals in this file to get the right params" or something like that. Not only is that not in the interview with Jamie, but even Joel's article doesn't say anything like that.
When you choose a name like "duct-tape programmer" you're basically guaranteeing that people are going to misread the article, as I believe you have. Anyway, best to ignore that particular work of Joel's and go straight to the interview with Jamie in the first place, if you want the real story.
This particular bug is simply a case of misreading a confusing spec in a subtle, and nobody catching it for years. That could happen regardless of your method or philosophy. Anybody coming into this and saying "oh unit tests would have nailed this!" or "oh that would never happen with Scrum!" is just cheerleading their favorite concept.
Re:Some kind of... (Score:5, Informative)
> (a leftover relic from the mainframe era that needed to die over a decade ago)
No no no. Binary coded decimal is necessary and useful. When you divide 1 by 10, you should get 0.1, not 0.10000000000000001 (which is what you get if you for instance open up a python interpreter and ask for 1.0 / 10.0).
Monetary amounts, and currency conversion rates are examples of something you should never, ever use standard binary floats for.
Fact: Many major databases use some form of BCD for representing currency values. Enough so that IBM added a dedicated decimal FPU for their power6 series - it's so common on business database servers that it actually saves a lot.
Re:10 hex is 16 decimal (Score:4, Informative)
The endianness may make it more sensible. If you have 0x12345678 represented using the correct endianess (the Intel one, not the Sun one), it'll be stored as 0x78563412. Using reverse nibble notation, it'll be 0x87654321.
But as far as I remember, it is caused by oldold ties to the 4004, which was a 4-bit CPU, inherited via the 8008 and 8080 by the 8086 and 8088.
Re:10 hex is 16 decimal (Score:1, Informative)
But IS it harder to read? For a human, yes. But, for a computer this makes perfect sense for a little endian computer. On a little endian machine (i.e. Intel x86), the bytes are stored sequentially from memory address zero up. If you grab large a 32-bit number and print it, you might see would see x0000000F. This makes things very easy for computer because a small number can be read from the same address as a 8 bit, 16 bit, and up without any need to adjust the offset (i.e. 0F = 15, 0F00 = 15, 0F000000 = 15). A big endian machine will make things follow Arabic numerals (i.e. 0F = 15, 000F = 15, 0000000F = 15). To correctly read a number, you have to adjust your offset to match the size of your number.
Now, we can also think about these mindsets when dealing with nibbles. A swapped nibble set means that for a computer each BCD encoded number becomes directly addressable on a little-ending machine straight up through memory. All I have to know is starting byte and the number of digits so I know when to stop. Fifteen years ago, saving code space was more important than being human readable. Swapped nibble encoding meant a simple algorithm to get each decimal:
byte_address = byte_address_start + decimal_count >> 2
byte = *byte_address -> byte_type
decimal = decimal_count mod 2 ? byte AND F0 >> 4 : byte AND 0F
Some machines have instructions in the processor to handle this type of behavior innately.
Re:Some kind of... (Score:3, Informative)
> (a leftover relic from the mainframe era that needed to die over a decade ago)
No no no. Binary coded decimal is necessary and useful. When you divide 1 by 10, you should get 0.1, not 0.10000000000000001 (which is what you get if you for instance open up a python interpreter and ask for 1.0 / 10.0).
Monetary amounts, and currency conversion rates are examples of something you should never, ever use standard binary floats for.
Fact: Many major databases use some form of BCD for representing currency values. Enough so that IBM added a dedicated decimal FPU for their power6 series - it's so common on business database servers that it actually saves a lot.
Here's [sun.com] a useful document from Sun on the matter (warning: pdf). The title is absolutely spot on: "What Every Computer Scientist Should Know About Floating-Point Arithmetic"