• phreddy (unregistered) in reply to Ben Jammin

    And if you have postcodes with leading zeros (we have some in Oz) then storing them as numbers don't work.

  • Jimbo Jones (unregistered) in reply to The MAZZTer
    The MAZZTer:
    KattMan:
    FRIST! and early

    Treat all numbers as characters unless you need to do math on them.

    I assume you mean PHONE numbers, otherwise this is just silly.

    Er, no. He means ALL numbers unless you need to do math on them (which is exactly what he said).

    If you don't need to do MATH with it, you likely only need it for display purposes or you might find you need to play string games on it anyway. I can't really think of a case where you'd want to store a number as a number except where there's math involved. Obviously something like a counter would probably be stored as a number, but its incrementing nature means it is being used for math anyway... (and though it may be stored in a DB as a number, it doesn't necessarily need to be treated as a number when we pull it out the DB unless we want to sort based on it later (where numbers might be a little more efficient)).

  • (cs) in reply to hymie
    hymie:
    You don't have numeric postal codes, numeric identification (Social Security) codes, numeric part numbers ... ?
    My national identification number starts with an X. In the previous country where I lived, by social security number started with a J.
    foo:
    A more pragmatic answer would be: "So you can preserve the puctuation and don't need extra code to remove it on input and add it on output", or "if you ever want to go international, note that some countries have numbers starting with 0".
    Either all foreign countries have numbers starting with 0 or they all have numbers starting with +. The latter is more portable.
  • JKR (unregistered) in reply to Spoe
    Spoe:
    Geoff:
    Not a PHP guy so I don't know but, if you try to convert a string to an int and its to big you get the largest possible signed integer value? Its not an exception, or overflow error?

    Yep. Much like many overflow conditions in C, e.g.:

    int foo ( int x) {
        return ( x+1 ) > x;
    }
    int main ( void ) {
        printf ("%d\n", ( INT_MAX+1 ) > INT_MAX );
        printf ("%d\n", foo ( INT_MAX ));
        return 0;
    }

    GCC (and several other compilers) with -O2 will output: 1 0

    Meaning INT_MAX + 1 is both greater than and less than INT_MAX depending on how it's calculated.

    No error is reported for the overflow. As I understand it, the behavior in this case is valid per the C99 spec since INT_MAX + 1 represents undefined behavior: the compiler can do what it wants.

    I don't see C receiving the same level of disrespect as PHP.

    Assuming that you mean 0,1 not 1,0 this is a compiler optimization, not a language quirk (ie it's a gnu thing not a C thing). Basically the compiler can see that x+1 will always be greater than x so it doesn't bother with the actual calculation at runtime. OTOH INT_MAX is just a macro and we have literal numbers substituted (which the compiler doesn't recognise as being the same) so we have to work out INT_MAX+1 (which overflows silently) to work out the inequality....

    As this is not behaviour defined in the standard, but rather something that happens on a specific compiler with a specific optimization setting it would be rather unfair to show disrespect to the language for it....

  • Drtfsxzjkl (unregistered) in reply to Meep
    Meep:
    Drtfsxzjkl:
    willaien:
    Akismet seems to think I'm spamming up the joint, so adding a bit of text below the URL.
    Akismet's algorithm is (or at least includes): if (post.endsWithURL()) then {is_spam = true}. I've yet to see a single counterexample.

    Well, any actual comment spam kinda has to have a link to work. And a lot of comment spam tends to be drawn from other comments, with a link thrown in. It's probably a pretty effective heuristic.

    But it does have quite a few false positives, given that there are at least three or four people complaining in every post.

  • Mick (unregistered) in reply to foo
    foo:
    A Person:
    Started at a new job about 6 months ago. Week 2 I am putting together some tables including you guessed it a telephone number.

    Boss looks at it later. 'Youre storing a phone number as text, why?'

    Little perplexed as boss is supposed to be a programmer.

    'Well you never need to perform arithemtic on it so this avoids any potential unintended math operations being performed on it'

    I expected a sage nod and for him to move on. What actually happened was the 3 other developers and my boss looked at me as if I was insane.

    It got stored as an int, and I realised I'm not going to learn anything here.

    The correct answer would have been: "Because it's not a number, just a sequence of digits." Of course, the chances he'd understand the difference are small.

    A more pragmatic answer would be: "So you can preserve the puctuation and don't need extra code to remove it on input and add it on output", or "if you ever want to go international, note that some countries have numbers starting with 0".

    Phone numbers are tricky, because people will have different conventions (which they sometimes alternate even for the same number).

    For example: The international dialing code for Australia is +61 An area code within Australia is 0X where: X=2 = NSW/ACT X=3 = VIC (and Tas?) X=4 = Mobile X=7 = QLD X=8 = SA/NT/WA There used to (I think they were taken out when the numbers went to 8 digits) be some localised area codes, like country SA was (085) instead of (08), but we digress

    For international callers, we drop the 0.

    There are then 8 digits for the number (which has increased from 6 or 7 about 20 years ago according to certain rules). Generally, the first 4 (formally 2 or 3) of these 8 digits represent the Telephone Exchange, although in the digitalized world this is no longer guaranteed - but we digress.

    Locally, most people used to leave off the area code (you can generally (excepting mobiles, I think) call other numbers within your area code without specifying it).
    Firstly, people seem to write mobiles down differently to local numbers, eg: 0412 123 123 for mobiles 8123 1234 (or (08) 8123 1234) for local

    But increasingly people seem to be realising that mobile numbers are the same as local numbers, and it's not uncommon anymore to see: (04) 1212 3123 (for the mobile above).

    So far, this isn't a major issue, because we can strip punctuation in comparison, and even cut off area codes if we detect them. It becomes more complex, however when we realise the following numbers are possible (but not necessarily) the same: +61 8 8123 1234 011 61 8 8123 1234 08 8123 1234 8123 1234 (AFAIK, this could e(at least theoretically) xist in an area code other than 08)

    Storing them is no issue as strings, but even as strings we have a problem of comparison - and a lot of takeaway stores seem to use the phone number to uniquely identify a customer....Of course, these issues are not necessarily insurmountable, but phone numbers are horribly complicated things, and are certainly not NUMBERS....

  • (cs)

    Exercise for the reader: devise a parser that can tell that 60608 is not a number but 6.022141e23 is.

  • Hoolio (unregistered) in reply to curtmack
    curtmack:
    This isn't the worst I've seen. Here's how MS SQL Server guesses data types in imported Excel spreadsheets:
    • Look at the top 20-ish rows.
    • Is any single one of them numeric?
    • If so, MUST BE A NUMBER!

    Thankfully, SQL Server does care about cell formatting (unlike Access, another program that has WTF Excel importing - you'd think Office would have pretty good compatibility with itself, but you'd be wrong). So if you format the column as Text, it won't type-guess.

    But as an added bonus, it silently fails to import numeric values into fields set up as varchars. And there's no option to tell it to explicitly cast numbers to strings either. So you get to import the data once to get all of the numeric employee IDs, import it again to get the non-numeric ones, and then merge them together.

    Edit: To be clear here - I mean that, even if it's from a column that you explicitly state is a string, SQL Server will still insist that "24593" is a number, and will fail to import it, presumably because it converts it from a string to a number, and then wonders why it can't put it into a string field.

    Even Excel doesn't seem to have much compatibility with itself if you want to use file formats other than its native....

    Try this: Open a new sheet, and in the first cell put

    "01"
    and in the second put
    =concatenate("0","1")

    Now save it as a csv file (accepting that some formatting may be lost etc). Open the csv in something other than Excel, and we see that the string with the quotes is stored """01""" and the one without is 01. Now reopen the file in Excel and (you guessed it) the 01 becomes a 1....

    IMHO Excel should be treating everything as a string when dealing with CSV format - especially something that has been created using a String function....

  • Daniel (unregistered) in reply to pjt33
    pjt33:
    Either all foreign countries have numbers starting with 0 or they all have numbers starting with +. The latter is more portable.

    Any country is free to choose whatever they like as their international access code. It is standardised as "00" across Western Europe and "011" in North America. Most other countries go along with one of those two but certainly not all of them. There are a few weird ones out there that don't even begin with "0". Some former Soviet states (including Russia) still use "8" and some other countries use various things beginning with a "1".

    As such, not allowing the user to enter a "+" is just asking for trouble. Who knows what they will enter instead? Maybe something flat out wrong? Maybe something right in their context but not in yours? Maybe something you need to decipher to work out? Maybe something you can't easily work out? Maybe something easily misunderstood as a local number?

    The failure to understand that people do things differently in other countries and that you need to accommodate them if you want their money is an endless source of WTFs. In addition to things that won't take a phone number with a "+" in it there are the forms that won't let you enter a postcode with letters in a (mandatory) "zip code" field and even a few that expect you to pick a US state when you don't live in one (although admittedly I have not seen that particular manifestation of idiocy for quite a while now). You would expect to see this only on forms where it is expected that the users are all local, which is fair enough in many contexts, but sometimes there is also a field for country which implies that they would like to do business overseas if only they knew how to.

  • Frank (unregistered) in reply to da Doctah
    da Doctah:
    Exercise for the reader: devise a parser that can tell that 60608 is not a number but 6.022141e23 is.
    /* returns 1 if input string is a number 0 if not and 2 if it is indeterminate*/
    int intParser(char *t)
    {
      if(strncmp(t, "60608", 5) == 0) return 0;
      if(strncmp(t, "6.022141e23", 11) == 0) return 1;
      return 2;
    }
    

    QED

  • Pizza Boy (unregistered)

    Noones mentioned house numbers.

    28A 1/27 U3/89 u2/57A 27-365 3 at 14

    etc

  • Tired Rabbit (unregistered) in reply to phreddy
    phreddy:
    And if you have postcodes with leading zeros (we have some in Oz) then storing them as numbers don't work.
    Here in the states it is the same.

    The only place I could possibly see using a number as a number is the house number (so if one wanted to sort by house along a street), but even THAT is a WTF because not all house numbers are integers, or numbers.

    PHP is such low-hanging fruit, why does Alex even bother posting them?

    [image]

    The way I see it, there are only two types of PHP programs:

    1. Initially written by a noob who really didn't know what he (or she) was doing, and managed to make every classic mistake in the book, or

    2. Some sucker who has to maintain the garbage written by #1.

    Face it, if you write a new application using PHP, you're doing it wrong. There is nothing that PHP does better except allow inexperienced people think they're skilled developers.

  • foo (unregistered) in reply to da Doctah
    da Doctah:
    Exercise for the reader: devise a parser that can tell that 60608 is not a number but 6.022141e23 is.
    The magic word you're looking for is context. When you get 60608 in your order-quantity field, it's a number, when you get it in the zip-code field, it's not. The problem (also in the OP, AIUI) is trying to parse and type-convert with too little context.
  • Norman Diamond (unregistered) in reply to Spoe
    Spoe:
    GCC (and several other compilers) with -O2 will output: 1 0

    No error is reported for the overflow. As I understand it, the behavior in this case is valid per the C99 spec since INT_MAX + 1 represents undefined behavior: the compiler can do what it wants.

    I don't see C receiving the same level of disrespect as PHP.

    Then you haven't looked very hard. Maybe the amount of abuse of C hasn't kept pace with the amount of abuse of PHP because it's easier for a larger number of less talented lusers to abuse PHP, but C had its share of critics in the old days.

    As for undefined meaning undefined, of course it would be expensive for implementations to diagnose all kinds of undefined behaviour and no one would want to incur that kind of expense all the time. But consider the Pascal standard, where the requirement is not that all kinds of undefined behaviour be diagnosed, the requirement is that implementations MUST OFFER AN OPTION where programmers can choose to require all kinds of undefined behaviour to be diagnosed. Pascal was vilified for providing an option for that amount of bondage and discipline. No one would ever accept such a safety measure in C. If people like that were in charge of automotive safety, seat belts would be illegal. People like that were in charge of nuclear power plant safety and see where that got us.

    C gets the disrespect it deserves, you just need to look harder.

  • Norman Diamond (unregistered) in reply to Jay
    Jay:
    foo:
    The US numbering system :) -- many countries' phone numbers start with an initial 0, so the previous mistake would show much earlier.
    That seems rather pointless. If all the numbers start with a zero, then the zero is superfluous and could be left off.
    That's the reason why international calls omit that zero between the country code and the remainder of the city code. However, most calls are domestic and the zero is needed to indicate that a full number is being dialled instead of a local (intra-city) number.

    Also, historically, long distance calls even within a single country were considerably more expensive than local (intra-city) calls. Also phones were dialled using dials instead of push buttons. So if a phone were offered for public use by a corner store or other public facing proprietor, they would put a lock in the 9 position in the dial. Digits 1 to 9 could be dialled but 0 couldn't be dialled (except by historical phone phreaks of course). Phone numbers didn't have any 0 digits except the first digit of the city code. So local calls could be dialled but long distance calls could not be dialled.

    Eventually pay phones replaced public use of phones provided by corner stores etc. (and later pay phones became obsolete because everyone except me carries a cell phone but let's not get ahead of ourselves), local numbers started to include embedded 0's the same as other digits, and the costs of calls were computed by some newfangled kind of calculating machine so it was no longer necessary to lock out the riffraff from dialling an initial 0.

  • John (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Jay:
    foo:
    The US numbering system :) -- many countries' phone numbers start with an initial 0, so the previous mistake would show much earlier.
    That seems rather pointless. If all the numbers start with a zero, then the zero is superfluous and could be left off.
    That's the reason why international calls omit that zero between the country code and the remainder of the city code. However, most calls are domestic and the zero is needed to indicate that a full number is being dialled instead of a local (intra-city) number.

    Also, historically, long distance calls even within a single country were considerably more expensive than local (intra-city) calls. Also phones were dialled using dials instead of push buttons. So if a phone were offered for public use by a corner store or other public facing proprietor, they would put a lock in the 9 position in the dial. Digits 1 to 9 could be dialled but 0 couldn't be dialled (except by historical phone phreaks of course). Phone numbers didn't have any 0 digits except the first digit of the city code. So local calls could be dialled but long distance calls could not be dialled.

    Eventually pay phones replaced public use of phones provided by corner stores etc. (and later pay phones became obsolete because everyone except me carries a cell phone but let's not get ahead of ourselves), local numbers started to include embedded 0's the same as other digits, and the costs of calls were computed by some newfangled kind of calculating machine so it was no longer necessary to lock out the riffraff from dialling an initial 0.

    I think the OP wasn't so much talking about getting rid of the need to DIAL 0 as the need to STORE 0....

  • Norman Diamond (unregistered) in reply to Zylon
    Zylon:
    Mcoder:
    That's because C is a low level language, without the concept of exceptions.
    Is C lower-level than any number of 8K BASICs that supported exception handling (known at the time as "error trapping") perfectly well?
    Yes, C is lower level than BASIC, _by_design_.
  • Michael J. Cohen (unregistered) in reply to willaien

    Sadly, Veekun's article is pretty wrong in and of itself.

    There are multiple in-depth analyses of what he got wrong floating around, but here's the HN thread that I most readily remember reading...

    http://news.ycombinator.com/item?id=4177516

    Akismet thinks I'm spamming, too. Silly software!

  • Nathan Hillery (unregistered) in reply to ekolis

    First name Max. Last name Int. Middle initial U.

  • foo2 (unregistered) in reply to foo
    foo:
    - Storing phone numbers (or zip codes etc.) as numbers - The US numbering system :) -- many countries' phone numbers start with an initial 0, so the previous mistake would show much earlier.

    Then it gets exported to .CSV, then opened in Excel which handily hacks the leading 0 off. Or converts it to scientific notation. Often both.

  • SDF (unregistered)
  • (cs) in reply to Jay
    Jay:
    Back in the early days of computers (I don't think so much today), many people would type the letter oh instead of zero and the letter el instead of one, which of course would then screw up numeric inputs. Manuals would routinely lecture users not to do this. Just because it looks right on a typewriter, it doesn't work on the computer, etc.
    Many typewriters didn't have a 1 and/or a 0 on the keyboard, because a lowercase l and uppercase O would look much the same, and that way the keys normally used for the 1 and/or 0 could be used for other symbols for which there would otherwise be no room. Anybody used to a typewriter would naturally type the same way on a computer, I'd expect.
  • (cs) in reply to Norman Diamond
    Norman Diamond:
    everyone except me carries a cell phone
    That statement is false — I have never owned a cellphone, and if it's left up to me, probably never will either.
  • Your Name * (unregistered) in reply to Nathan Hillery
    Nathan Hillery:
    First name Max. Last name Int. Middle initial S.

    FTFY

  • foxyshadis (unregistered) in reply to foo
    foo:
    Let's see, TRWTFs are: - Type-guessing -- honestly, in all my programming work I never needed to type-guess. Either the input fits the expected type, or it's invalid. - Not immediately thinking of 2^31 when seeing a 10-digit number starting with 21... (OK, slight excuses for the Dallas coincidence, but when a certain "magic" value keeps popping up, you better look what kind of value it actually is.) - PHP doing saturation rounding, apparently without any warning, in a type-cast - PHP itself - Testing on a different configuration that production - Storing phone numbers (or zip codes etc.) as numbers - The US numbering system :) -- many countries' phone numbers start with an initial 0, so the previous mistake would show much earlier. - The article: * Typo/grammar error in the first sentence * "2,147,483,647 is the highest integer value addressable on 32-bit systems". Triply wrong: (a) The highest *signed* integer, (b) representable, not addressable, (c) in a single register (64 bit integers stored in two registers are not that exotic, though maybe in PHP) - The comments, including this one - Akismet, of course

    As a consultant, am I supposed to keep identical copies of every 32-CPU server I'm still supporting and might-be supporting around the house, just in case one of them calls me up to fix something?

  • foxyshadis (unregistered) in reply to Pizza Boy
    Pizza Boy:
    Noones mentioned house numbers.

    28A 1/27 U3/89 u2/57A 27-365 3 at 14

    etc

    I pity the poor misguided son of a gun trying to micro-optimize a few bytes out by storing house numbers as integers, but has anyone actually done that? Everyone seems to associate the house number with the street name.

  • Stephen Griffith (unregistered) in reply to John Winters

    You have to store them unconventionally if a user could live in another country.

  • Stephen Griffith (unregistered) in reply to Tired Rabbit
    1. Cheap hosting is another reason.
  • My Name (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Zylon:
    Mcoder:
    That's because C is a low level language, without the concept of exceptions.
    Is C lower-level than any number of 8K BASICs that supported exception handling (known at the time as "error trapping") perfectly well?
    Yes, C is lower level than BASIC, _by_design_.
    +1. "Old, limited and probably a bit painful" doesn't imply "low-level".
  • Captain Boolean (unregistered)

    All this talk of 'numbers as text, unless you need to do maths (yes, I'm British)'...

    What if you're designing a data warehouse for conspiracy theorists? That'd be a long running project I reckon!

  • (cs) in reply to Daniel
    Daniel:
    pjt33:
    Either all foreign countries have numbers starting with 0 or they all have numbers starting with +. The latter is more portable.

    Any country is free to choose whatever they like as their international access code. It is standardised as "00" across Western Europe and "011" in North America. Most other countries go along with one of those two but certainly not all of them. There are a few weird ones out there that don't even begin with "0". Some former Soviet states (including Russia) still use "8" and some other countries use various things beginning with a "1".

    As such, not allowing the user to enter a "+" is just asking for trouble. Who knows what they will enter instead? Maybe something flat out wrong? Maybe something right in their context but not in yours? Maybe something you need to decipher to work out? Maybe something you can't easily work out? Maybe something easily misunderstood as a local number?

    We seem to be in violent agreement. My comment about beginning with 0 was addressed specifically at a comment which implied that the international access code varies according to the country you're calling to, which would be crazy. I suppose I can't rule out the possibility that there is some country that crazy, but...

    The failure to understand that people do things differently in other countries and that you need to accommodate them if you want their money is an endless source of WTFs. In addition to things that won't take a phone number with a "+" in it there are the forms that won't let you enter a postcode with letters in a (mandatory) "zip code" field and even a few that expect you to pick a US state when you don't live in one (although admittedly I have not seen that particular manifestation of idiocy for quite a while now). You would expect to see this only on forms where it is expected that the users are all local, which is fair enough in many contexts, but sometimes there is also a field for country which implies that they would like to do business overseas if only they knew how to.
    One of the worst examples I've seen of this is the paper form for British citizens who wish to register as overseas voters. So logically the only people who could reasonably fill in this form will have addresses outside the UK, but their addresses will be held on record in the UK. And yet the section in the form for the address doesn't have a space for the name of the country in which the overseas voter is living. WTF?
  • Marc (unregistered) in reply to The MAZZTer
    The MAZZTer:
    KattMan:
    FRIST! and early

    Treat all numbers as characters unless you need to do math on them.

    I assume you mean PHONE numbers, otherwise this is just silly.

    No, it's not. It goes for things such as international standard book numbers, project numbers, employee numbers etc. just as well. Thing is, these are not really numbers, but keys.

    You can't add project 4 to project 6 and expect the outcome to be project 10.

    Incremental, numeric keys are a bad idea, anyway - they're a one-way trip to unscalable applications.

  • (cs) in reply to Pizza Boy
    Pizza Boy:
    Noones mentioned house numbers.

    28A 1/27 U3/89 u2/57A 27-365 3 at 14

    etc

    Why this insistence on houses having numbers at all? There are other ways of giving properties unique addresses.

  • Anon (unregistered) in reply to dkf
    dkf:
    Pizza Boy:
    Noones mentioned house numbers.

    28A 1/27 U3/89 u2/57A 27-365 3 at 14

    etc

    Why this insistence on houses having numbers at all? There are other ways of giving properties unique addresses.

    Because house numbers are usually, sort of, ordered. If you're looking for 1038 whatsit road and you just passed 1012 and 1014 whatsit road, you know you are moving in (probably) the right direction.

    Unfortunately, it's often broken. My brother-in-law lives in a house with a number in the thousands. A couple of doors up the house numbers are in the tens of thousands. Very weird.

  • Aaron (unregistered)

    This is actually a really good, interesting, and useful, WTF. Can we have more of these please?

  • (cs) in reply to Aaron
    Aaron:
    This is actually a really good, interesting, and useful, WTF. Can we have more of these please?

    What, and break with tradition? Are you crazy?

  • Qŭert (unregistered) in reply to foo
    foo:
    The correct answer would have been: "Because it's not a number, just a sequence of digits." Of course, the chances he'd understand the difference are small.

    Some human languages have this difference built-in, e.g. in Esperanto. "Because it is not a numbro, just a numero" (same as in French: nombre and numero)

  • Qŭert (unregistered) in reply to Qŭert

    numéro in French, I mean.

  • (cs) in reply to Mick
    Mick:
    There used to (I think they were taken out when the numbers went to 8 digits) be some localised area codes, like country SA was (085) instead of (08), but we digress

    Yes, in the 1990s we went from 50-odd area codes to four, with the first few digits of the local number being of geographic significance. Confusing area codes like Hobart (002 or +61 02) were changed (to (03) 62 or +61 3 62). Most numbers only had a digit inserted, or other minor change. (085) became "(08) 85" which would have since been "overlaid" with "(08) 75". The renumbering also opened up the entire 04 range for mobile phones: 0G and 1G systems had various 00x and 01x prefixes while GSM started in 1992 with 041x. And there's talk of opening up 05 for mobiles too. One hundred million numbers is not enough for our population of 20-odd million!

    Mick:
    There are then 8 digits for the number (which has increased from 6 or 7 about 20 years ago according to certain rules). Generally, the first 4 (formally 2 or 3) of these 8 digits represent the Telephone Exchange, although in the digitalized world this is no longer guaranteed - but we digress.

    I know very few exchanges with a full 10,000 number block: they are mostly in blocks of 1000. You can actually download a list from the Telstra website! (Starting from page 256 of the PDF)

    Mick:
    It becomes more complex, however when we realise the following numbers are possible (but not necessarily) the same: +61 8 8123 1234 011 61 8 8123 1234 08 8123 1234 8123 1234 (AFAIK, this could e(at least theoretically) xist in an area code other than 08)

    Those are all the same number, depending where you call it from. +61 is the international prefix, it removes all ambiguity (AFAIK all mobile phones let you enter a literal "+" so you don't need to know about 00 or 011 or 0011 or 8~10 or whatever country you are in). 011 is "+" for the USA, Canada, et al. With the 08 is valid calling from anywhere in Australia, and without it is valid calling from anywhere in the 08 code - like a normal open dialling plan. (WA, NT, SA, and parts of western NSW) Indeed if you called 81231234 from the rest of NSW it could be a valid number in Sydney.

    If I were in charge of numbering I'd "close" the numbering plan, remove all "area codes" and give everyone nine digit numbers. Internationally very few numbers would change (only some within +611); local numbers would gain a 2, 3, 7 or 8; while inter-area calls and mobiles would drop their initial 0. And while I'm at that I'd remove the notion of "local call" vs "long distance": calling interstate is no different to calling next door - I already get this from my voice provider.

    Mick:
    Storing them is no issue as strings, but even as strings we have a problem of comparison - and a lot of takeaway stores seem to use the phone number to uniquely identify a customer....Of course, these issues are not necessarily insurmountable, but phone numbers are horribly complicated things, and are certainly not NUMBERS....

    I used to work at a pizza place that did that. All phone numbers were obviously stored as ints, but since the numbering plan is known and with nine significant digits it sort of made sense. I worked in the city which was "(07) 46xx xxxx". If you entered "21" as the phone number it became "07 4600 0021". This was handy because you could just enter the old-style six digit phone number and it would work itself out. If you entered a mobile number as nine digits beginning with 4 (or ten with 04) it would generally work, but they kept having to update the system to handle newer ranges. I remember when the 0438 range was released: entering 0438123456 would actually become "07 4612 3456". Whoops!

    However, at the newest store entering "555123" actually became "07 0055 5123" because numbers beginning with 45 were introduced, which did cause some problems when going between stores. (Another WTF was the older stores had membrane keyboards and the new one had standard 101 keyboards, so you needed to know the codes the membrane keyboards would have sent out, like NAZ for $5.95 voucher or GAR for garlic bread. But I'm digressing; the computer system was replaced with a touchscreen system after I quit in 2005. The old system was a single P166 for the entire store using Wyse terminals)

  • (cs) in reply to Jay
    Jay:
    foo:
    The US numbering system :) -- many countries' phone numbers start with an initial 0, so the previous mistake would show much earlier.

    That seems rather pointless. If all the numbers start with a zero, then the zero is superfluous and could be left off.

    Most countries with the initial 0 would be the equivalent of an American saying a phone number is "1212-555-1212". The 0 is the trunk prefix which is not used when dialling from International. But then the NANP is unique in that your trunk prefix of 1 is the same as your country code, so my example includes the trunk prefix; to be completely correct from an international perspective that number should be "+1.2125551212".

  • (cs) in reply to Maurits
    Maurits:
    At the risk of being tautological, if you don't need to do math on the thing, it's not a number, it's just an identifier.

    I'll add ISBNs and PINs to KattMan's list, and subclass part numbers as UPCs and EANs.

    But EANs (of which ISBNs and UPC are subsets) have check digits that you add and modulo to ensure you have read the number correctly. That sounds like maths to me.

  • (cs) in reply to Zemm
    Zemm:
    Maurits:
    At the risk of being tautological, if you don't need to do math on the thing, it's not a number, it's just an identifier.

    I'll add ISBNs and PINs to KattMan's list, and subclass part numbers as UPCs and EANs.

    But EANs (of which ISBNs and UPC are subsets) have check digits that you add and modulo to ensure you have read the number correctly. That sounds like maths to me.

    I wouldn't, because you do not do math with the entire set of digits, rather you pull it apart into its separate digits and then do math on that. It is a series of characters that fall within the range of 0-9 that you will split (string operation) then convert to numbers and perform a checksum calculation on.

    If you saved it as a number field (int, double, float whatever) you would have to convert it to the string to split it then convert the pieces back to ints and do the math. Cut out one of those operations since you are not doing math on the original string of digits.

    Edit: I will further mention those UPC codes or EAN's that begin with 0, save it as a number and you won't have the right number of digits to perform your checksum on, save it as a string and you will preserve your true EAN or UPC value.

  • Justin Reese (unregistered)

    Hi all. I'm the dummy who both wrote the dumb code and submitted the story. Let me clear up a few misunderstandings.

    foo:
    Type-guessing -- honestly, in all my programming work I never needed to type-guess. Either the input fits the expected type, or it's invalid.

    Absolutely. This was my critical mistake. My reasons for doing this were unsound, but even unsounder was introducing it so deep in the library chain that I didn't even realize the phone number had been touched by it. Immediately after discovering the bug, I removed the type-guesser and apologized to mankind.

    Not immediately thinking of 2^31 when seeing a 10-digit number starting with 21... (OK, slight excuses for the Dallas coincidence...

    No, not a slight excuse, that's the whole reason. If this had been in, say, an "annual salary" field, it may have jumped out faster. But it was showing up in a phone number field, and being massaged by the template into XXX-XXX-XXXX format, and we're from Dallas (where 214 is everywhere).

    ..., but when a certain "magic" value keeps popping up, you better look what kind of value it actually is.)

    Which is what I did. Which is why I found the bug. Hey your hindsight is as good as mine!

    Testing on a different configuration that production

    Alex introduced an error when he massaged my article. The testing and production boxes are identical, and both exhibited the error. It was only on my dev box (64-bit) that things worked properly.

    Speaking of which: you guys know Alex/team re-write the submissions, right? The basic facts of the story, and some of my original language – glad you guys liked the "pardner" – are here, but much of the color and some of the details are his. I didn't actually blame a co-worker or boss, test and production were both 32-bit, and I didn't actually learn anything from this.

    Storing phone numbers (or zip codes etc.) as numbers

    The numbers were stored (and transmitted) as strings; it was my dumb type-guesser in the XML-reading library that broke things.

    validus:
    No, dude. What you should have learned from that is that your suck as a coder, and that your logic is not quite there yet.

    I'll not give you the former, but given that I submitted an embarrassing, self-incriminating story to a website of my peers, I'll give you the latter.

  • Justin Reese (unregistered)

    I just realized it doesn't come through in the article, but the phone number was only being int'ed before being sent to the template for rendering. It was a safe and happy string in the database and in the XML.

  • Justin Reese (unregistered)

    Also I wasn't doing it specifically to phone numbers, but to all strings that looked like numbers, which really was even stupider but it was a late night and I'd had lots of wine* and nobody checks my code before it goes into production.

    *It was probably 10am and I was fully alert.

  • Greeno (unregistered)

    The main problem with storing phone number as number would be the loss of preceeding zeros.

  • Mozzis (unregistered) in reply to Spoe

    If I am writing in C, it is at least partly because I don't want all of the hand-holding and its associated overhead that would be implied by a check for overflow everytime I added two numbers together. And don't tell me it can be done in "only a couple of assmembly instructions" - if I am using C, I expect maximum performance, and if results need checking, I will do it myself thank you very much.

  • Ol' Bob (unregistered)

    From "The Tao of Software":

    Programming languages which require that developers know and care about the number of bits in a numeric variable are ill-suited for business use.

  • Ol' Bob (unregistered) in reply to dork
    dork:
    now whos gonna call the max int32 phone number and try to convince them if they switch to at&t they will get full 64bits of service!

    ...and even now, deep in the bowels of the advertising department, some junior copyrighter is running to his boss screaming "HEY! BOSS!! I GOT ME A IDEER!!!".

  • (cs) in reply to Marc
    Marc:
    You can't add project 4 to project 6 and expect the outcome to be project 10.
    What if project 4 is yellow paint, project 6 is blue paint and project 10 is green paint?

Leave a comment on “Confessions: The Phone Number”

Log In or post as a guest

Replying to comment #:

« Return to Article