Most common “Y2K-style” bugs today? [closed]

Question

I don't specifically mean date-related issues like 2038, but more generally, bugs that fit the pattern:

• A generation ago, programmers tended to write code that ass-u-me-d X, which was reasonable at the time.
• But circumstances have changed, and now X is a common source of problems that need to be fixed.

For example:

• X = "Memory is too expensive to justify storing all 4 digits of the year. Don't worry about 2000; that's a long way off." (broken by Y2K)
• X = "Who needs size_t? We can just use unsigned int." (broken by 64-bit systems)

Answer 1

IPV4 only networking code. The time hasn't come for most people yet, but the idea of IPV4 only networking will become obsolete.

Answer 2

Many localization issues fit this pattern:

• a generation ago, programmers assumed all characters can be represented with an 8 bit data type
• a generation ago, programmers assumed every kind of text should be read left-to-right, top-down
• a generation ago, programmers assumed the field separator in a CSV file is always the comma character , (No, it really isn't. CSV is the file extension, not the file format specification. My guess is, when CSV was invented, it actually was just comma separated values. As it evolved, nobody wanted to rename it to "tabular data file with locale-dependent column separator, quoted fields for field values containing a separator character and double quotes for quote characters".)

Answer 3

Validators for domain names making wrong assumptions like:

• TLD is 2-3 characters long (not true since 2001);
• domain names and TLDs contain only US-ASCII characters (not true since January 2010);

Answer 4

I did some research on y2010 about 14 months ago:

printf("200%d", year);

Believe it or not, code like that exists.

Answer 5

Another one not yet touched on are applications (and especially websites) assuming that all addresses are US addresses. In an era where international business is increasingly vital, this is causing trouble. Companies are loosing out on possibly lucrative business because customers find themselves incapable of placing orders.

This is especially critical with postal codes/zip codes and phone numbers. Numerous applications and websites validate these against the US system, incorrectly assuming that's the only system that exists (when in fact a lot of the planet uses different systems, and there are countries without any postal codes). A smaller problem is demanding house numbers in addresses, when there are still locations without them (small villages) and sometimes even street names.

Heard a story last year about someone in a small village in France trying to order a phoneline installed (he was just moving there) and finding it impossible as the computerised system used by the provider wouldn't accept his address which existed only of the name of the house and village (no street name, no house number, no postal code).

Answer 6

Single-byte encoding (ASCII, ISO-8859-x) vs multi-byte encoding (Unicode, UTF-8). That's currently the biggest legacy issue I can think of. There is just so much software that assumes that strings' byte length == character length.

Answer 7

IPv4 comes to mind. We're running out of IP addresses (in fact it may already have run out, the last batches have been distributed to regional authorities).

Introduction of the replacement IPv6 is slow as hardware and software manufacturers are catching up.

Answer 8

Something that got me royally badly a few months ago was cookie expiration dates...

Apparently, cookie expiration dates can be set only so far forward into the future (correct me if I'm wrong on this point - not an expert on this myself!). Anyway, a few months ago a really bizarro login problem came up with an app that our team was maintaining. But, this was a side-project, and this login component was really solid, didn't have to be touched in 10 years, so nobody was around who even knew how it worked (never had to touch it for how solid it was).

Anyways - after half a day of digging around and losing my mind I noticed there was a hard-coded date of 31st December 2010 in a validation routine. So basically anyone who was trying to use the system with a newer cookie couldn't log in. Turned out this was hard-coded way back in 2001, because they couldn't set a cookie expiration date beyond 10 years into the future - and the programmer at the time was too lazy to make it a "floating date".

Answer 9

Security.

Storing unhashed passwords, leaving "back doors" in applications, using languages that have buffer overflows. See the OWASP top 10 for the current list of dumb assumptions.

Answer 10

Doing any kind of date arithmetic (addition/subtraction) directly on a UNIX Epoch time integer, for example:

gmt_epoch
1301397219
March 29, 2011 11:13:39 GMT

and you want to figure out the correct time for the east coast of America, EST (-5:00 GMT), so you do something like:

gmt_epoch-(5*60*60)
1301379219
March 29, 2011 06:13:39 EST

which is WRONG, because March 29, 2011 happens to be EDT (-4:00 GMT).

This isn't so much a Y2K caliber bug, as you don't have to wait 10 years to see its affect, but, say you hire a contract programmer who is only working on the project for a month or so, then, BAM! the thing breaks after daylight savings time ends.

Answer 11

Timezone support and usage. How many systems have you seen that just have dateStarted or dateCreated without any acknowledgement or notation on which timezone is considered the base? Hopefully it's GMT/UTC but counting on that is risky at best.

Answer 12

In the UK when the VAT rate changed from 17.5% to 15% in December 2008 it was the first change to VAT since 1991 and a lot of programs had the value hard coded into them.

The change also meant that the system had to separate out VAT rates based on date, because it wasn't going to be just as simple as changing a constant value somewhere.

Hopefully they were all ready when it changed back (and then increased)!

Answer 13

Developers - or DBA's - who assume that everyone's name falls into the familiar (to western eyes) pattern of FirstName and LastName.

• In many Asian countries, the name of the family traditionally comes first because of a cultural value that places the needs of the family over the needs of the individual. Writing "Bevan Arps" can be considered disrespectful, even rude.

• In other parts of the world, families don't have names - people are referred to by their (only) name. If there might be confusion, their parents or trade are referenced as well.
  [Aside: This is also the source of many western family names like McGreggor (son of Greggor), Mathieson (son of Mathie), O'Connor (son of Connor), Carpenter, Smith, Butcher and Taylor.]

• Not everyones name has a long spelling - "N" and "O" are the english spellings of genuine names, but many systems reject the names as too short.

• Not everyone's surname is short enough to fit into a 50 character field either.

• Not everyone's name gets capitalised the same way. Some people write their surname "van den ..." others "Van Den ..." and adjusting it is wrong.

Answer 14

One assumption is that our business won't have to grow to non-US (or non-English-speaking) markets. Internationalization when you've done everything right to begin with is a big project. When most of your strings are hard-coded into the code, it's a much bigger project.

There's also assumptions that people make regarding languages.

You can convert between upper and lower case freely (broken in German, with the beta-like eszet character converting into two uppercase Ss).

You have singular and plural forms (some languages have dual forms in addition).

A non-modifier keypress produces a character (friend of mine got hit by a problem that happened when hitting ESC after typing a consonant to form the first part of a Japanese syllable, as katakana and hiragana are syllable alphabets).

Answer 15

Not using an XML library to write XML.

The level of frustration you get when dealing with malformed XML files can sometimes be too much. print "<data>$value</data>"; will most likely fail.

There are so many XML libraries out there that you are bound to find one easy to use. Seriously - stop reinventing what others have spent a lot of resources on already. You may think you know XML but more things can go wrong than you may expect.

Answer 16

The programmer's assumption that a user's geographical location should automatically define that user's preferred language. IP-to-location technology should not be used for preferred language decisions.... ever. Even Google and Facebook are guilty of this one.

Answer 17

Using an integer to store currency in its least form. Say cent's. Tomorrow you might use a new currency, it happened in many European countries.

Storing static Vat-rates for categories etc in webstores. In many countries vat rates are considered to be static, but the idea is not to have them static and once in a while they are changed.

Storing civic numbers in a specific notation and use it as a key (or any other "natural key" stuff); tomorrow you might have million of refugees from china, will their civic number look like yours? (Today this is already the case in Sweden)

Assuming 0 is NULL in databases. Next SQL-standard might start count from 0, who knows? :-)

Answer 18

I'm just glad I won't be around for the Y10K apocalypse.

Answer 19

Assuming a primary key derived from application data will never need to be changed. The most common example is user id - it's usually impossible to change, even if the user changes their name.

Other examples I have come across - assuming country codes never change, currency codes, city names.

Answer 20

Serial vs parallel processing. Multi core processors are or will be soon seen as universally ubiquitous, with exception of very product or task specific hardware.

Answer 21

Well, it kind of fits this question, I guess.

Basically, unsecured WiFi networks. Apparently the standards organizations somehow thought something along the lines of "Oh, only good guys will use open WiFi networks!", so they decided to never encrypt it in any way. I mean, isn't that the type of thing that the Diffie-Hellman encryption key exchange was made for?

This is a pretty big problem today, with things like Firesheep being used fairly widely.

Answer 22

Just because Y2K is over doesn't mean programmers are done writing date and time bugs. There were whole families of bugs that struck near and about year 2000. The date and time bugs that continue to arise keep entertaining me in their creativity.

While it's old and becoming dated, the following enjoyed some popularity on the run up to year 2000 and still has some current information.

http://www.exit109.com/~ghealton/y2k/yrexamples.html

While legacy hardware my eventually die, legacy data formats live on and on.

Answer 23

32 bits counter in various networking hardware MIBs. They can wrap pretty fast and yet sometime are used for billing...

Answer 24

Not quite the same, but the number 10100401822940525 does not exist in Javascript or ActionScript 3.

Specifically, we found that the number 10100401822940525 appears to simply not exist in these programming environment. You can test this for yourself, simply trace or log the following statements: 10100401822940524 10100401822940525 10100401822940524+1 Number(“10100401822940525″) (10100401822940525).toString()

All of the above statements will output “10100401822940524″, when obviously all but the first one should return “10100401822940525″.

Theres no obvious significance to that value. The binary/hex value isn’t flipping any high level bit, and there are no results for it on google or Wolfram Alpha. Additional testing showed the same result with other numbers in this range.

Mystery solved here:

• http://gskinner.com/blog/archives/2011/03/the-case-of-the-disappearing-number.html