The most common phone number: 214-748-3647 | Hacker News Reader

The most common phone number: 214-748-3647

sharkbait.computerworld.com

146 pointssolipsist61 comments

This sounds apocryphal to me. I mean, how would anyone build a system where no number above 2147483647 can be stored and not notice it? I mean, that excludes the vast majority of phone numbers.

EDIT: Maybe I give mankind too much credit. Search for a non-Dallas city here: http://24hourplaces.com/search.php

I am never surprised when code is written without decent testing good testing is the exception rather than the rule.

This goes well beyond simply not having good testing though. It requires not testing and disconnecting the phone line and email so you can't get customers' bug reports. And never using the thing yourself.

I agree, it seems fishy to me that saturation rather than wrap is the integer overflow behavior in these systems.

Saturation is standard behavior of C's atoi() and friends. Over/underflow is signalled by returning largest/smallest possible value and setting errno to ERANGE. Many applications dont check for this (as it is not exactly straightforward) and thus get saturation.

MySQL does this too. I once found a bunch of Facebook User IDs that were all 2147483647 after someone missed the memo that Facebook was transitioning to BigInts.

Wow, that's unbelievable. Almost any phone number in 24hourplaces.com is that Dallas number. How come the owner of that website never noticed?

http://www.google.com/search?q=214-748-3647

The fascinating thing is that there are significantly sized urban areas with area codes < 214 (such as much of NY,NJ, Washington DC). Do these business survive off of customers just in those areas and they never pay attention to the fact that their systems are horribly broken?

Yikes. People store phone numbers as integers? Why would anyone do that?

Is there some use-case where being able to treat a phone number as an integer value has any usefulness?

"A string of characters acting as numbers? Hell no. People could put in anything. '234-fake-num' isn't a real phone number! This way we'll be sure the numbers are real. Besides, look how much space we'll be saving."

Bad idea as celoyd pointed out. Besides, to check whether a phone number is real or not we use regular expressions.

I think he was being facetious...

I don't think zck was arguing for phone numbers as integers. I think he was just dissecting the broken thinking that would cause someone to make that decision.

To check if a phone number is real, it's best to call it.

My google voice number is 786-J-Finnie... I really hate that I can't enter that on a vaild phone number on many websites! Since I specificially looked for that as a phone number, I haven't memorized the actual numers of JFINNIE, so I just put in a fake number.

Well, it will be smaller on disk.

I know next to nothing about the phone system, but in some countries there are legitimate numbers starting with 0. So among the many problems with this practice, it puts an arbitrary technical limit on your market.

Converting the phone number to hex and then storing them as character bytes as opposed to long integers, might save even more space on disk at the cost of hex-decimal conversion :)

hexadecimal is used, because the conversion is almost free (as oposed to decimal)

Also, phone numbers (for last 50 years or so) actually are hexadecimal strings (with extra characters - denoted ABCD*# - reserved for various special purposes).

Considering I work with graduates who were 10 when the whole Y2K thing was news I am not surprised.

Yup. If they were older, they'd realize just how little a deal y2k was.

And if they were older than that, they'd remember that a number of people were employed to fix y2k bugs before they became problems.

Y2K was such a little deal because so much effort went into fixing it. It's hard to say how big the problem would have been but considering that many financial systems would have been affected it probably would have been fairly significant.

It seems like if this explanation were to make sense, whoever implemented the string-to-number conversion was careful enough to implement saturating addition, but careless enough to not use a numerical type large enough to hold every possible phone number. I don't know if I buy that.

Perhaps they just used strtoi() or some such equivalent in their language.

If you page through the Google results, there's actually less than 400 pages listed.

See: http://blog.xkcd.com/2011/02/04/trochee-chart/

"Please press 1 now." Then, after a while: "Press press one now. If it is a person and not a computer calling, press 1 now.". Then, again after a while: "Press one of it will disconnect."

why wouldn't it wrap around?

Integer overflow behavior varies a lot between languages; it can be undefined, some wrap around, others promote to a larger integer type, others convert the type to something else, and some clamp to the largest (or smallest) value.

For example, if you're using PHP, an integer will turn into a float when it overflows; if you then push the value into a MySQL databse, it'll be clamped.

Scary thought: this bug is nice and obvious when the data gets "clamped" to max_int, but what about when it doesn't and overflows to some value in the middle? No way to tell how many systems suffer from that flavor.

> there are 1500+ websites with that phone number showing up.

Just to note, article is from 2008. Current figure is: About 316,000 results (0.13 seconds)

Also, he didn't even bother calling the number to see who owns it? Sloppy.

http://www.yellowpages.com/phone/?phone_search_terms=214-748...

i called it but couldn't figure out what the business actually was.

interesting fighting about computer science etc.

i'd say, not to store phone numbers in integer field require just one advice of an experienced colleague, no need in 5 years course (assuming a guy doesnt put boots on his head in other parts of his work)

Reply on news.ycombinator.com