ZIP Code FAIL



  • I posted about this before but I didn't have any photographic evidence then.

    [img]http://images.mzzt.net/IMG_0695.jpg[/img]

    Yeah, for the record, the ZIP code for the area is 08036.

    II noticed this a number of months ago and it's been this way on every receipt I've gotten from them since then.



  •  The web site claims that the ZIP code is 08060.  If that's the case then this is simply some misapplied formatting/padding.

     



  • Looks like somebody used strtol() which tried to do octal->binary conversion.



  • @alegr said:

    Looks like somebody used strtol() which tried to do octal->binary conversion.

    You sure?  That looks like someone used strtol() which started to do octal->decimal conversion, but aborted at the first invalid character.  If endptr was not NULL, it was given a pointer to the 8; otherwise, there was no way for the program calling strtol() to recognize that there was a problem.



  •  Thats nothing, the postcode in an inhouse application here is stored as an int.

    ( I wish i was joking. )



  • @Spikeles said:

     Thats nothing, the postcode in an inhouse application here is stored as an int.

    ( I wish i was joking. )

    You should add support for alpha characters in the postcode by using a signed 64-bit int: if it's positive, it's all numeric.  If it's negative, you interpret the entire thing as a series of 5-bit values which map into 0-9 (0 to 9) and A-Z (10 to 36).  This would give you the ability to store up to 12 characters of an alphanumeric postcode.



  • Morbs? Why does your sig now include the linked logo of a Hungarian telecom?



  • @TwelveBaud said:

    Morbs? Why does your sig now include the linked logo of a Hungarian telecom?

    It's for Welpog.



  • @morbiuswilters said:

    Filed under: I love Welpog.
     

    Bad news, fellow Welpog-lover.  He cut off his adorable 'fro.



  • @TwelveBaud said:

    Morbs? Why does your sig now include the linked logo of a Hungarian telecom?
    SEO, fool!  Morbius recently invested in said company.



  • @tgape said:

    @alegr said:
    Looks like somebody used strtol() which tried to do octal->binary conversion.

    You sure?  That looks like someone used strtol() which started to do octal->decimal conversion, but aborted at the first invalid character.  If endptr was not NULL, it was given a pointer to the 8; otherwise, there was no way for the program calling strtol() to recognize that there was a problem.

    Eh.. OK. strtol() does str to long, where the long is 32-bit (usually) binary. Because it encountered '8', the result was 0. That's what I was trying to say. Which is what you essentially repeated. Of course, the sensible approach should be to provide 'radix' argument of 10 instead of 0.


  • @morbiuswilters said:

    @Spikeles said:

     Thats nothing, the postcode in an inhouse application here is stored as an int.

    ( I wish i was joking. )

    You should add support for alpha characters in the postcode by using a signed 64-bit int: if it's positive, it's all numeric.  If it's negative, you interpret the entire thing as a series of 5-bit values which map into 0-9 (0 to 9) and A-U (10 to 31).  This would give you the ability to store up to 12 characters of most alphanumeric postcodes.

    FTFY.  Or, since they have to rewrite it anyway, do it right, and not get a strange bug where the letters V-Z appearing in a postcode cause it to be re-written to a slightly different postal code, with a 0-5 in the place where the V-Z was, and either the digit before or the digit after being increased by one.

    Yeah, you could use 6-bit packing, but then you only get 10 characters of alphanumeric postcodes, and you have ancient bitstream operators in your conversion code, which nobody (your management choses to afford) understands.



  • @tgape said:

    @morbiuswilters said:

    @Spikeles said:

     Thats nothing, the postcode in an inhouse application here is stored as an int.

    ( I wish i was joking. )

    You should add support for alpha characters in the postcode by using a signed 64-bit int: if it's positive, it's all numeric.  If it's negative, you interpret the entire thing as a series of 5-bit values which map into 0-9 (0 to 9) and A-U (10 to 31).  This would give you the ability to store up to 12 characters of most alphanumeric postcodes.

    FTFY.  Or, since they have to rewrite it anyway, do it right, and not get a strange bug where the letters V-Z appearing in a postcode cause it to be re-written to a slightly different postal code, with a 0-5 in the place where the V-Z was, and either the digit before or the digit after being increased by one.

    Yeah, you could use 6-bit packing, but then you only get 10 characters of alphanumeric postcodes, and you have ancient bitstream operators in your conversion code, which nobody (your management choses to afford) understands.

    Man, how did I fuck that up?



  • @morbiuswilters said:

    @tgape said:

    @morbiuswilters said:

    @Spikeles said:

     Thats nothing, the postcode in an inhouse application here is stored as an int.

    ( I wish i was joking. )

    You should add support for alpha characters in the postcode by using a signed 64-bit int: if it's positive, it's all numeric.  If it's negative, you interpret the entire thing as a series of 5-bit values which map into 0-9 (0 to 9) and A-U (10 to 31).  This would give you the ability to store up to 12 characters of most alphanumeric postcodes.

    FTFY.  Or, since they have to rewrite it anyway, do it right, and not get a strange bug where the letters V-Z appearing in a postcode cause it to be re-written to a slightly different postal code, with a 0-5 in the place where the V-Z was, and either the digit before or the digit after being increased by one.

    Yeah, you could use 6-bit packing, but then you only get 10 characters of alphanumeric postcodes, and you have ancient bitstream operators in your conversion code, which nobody (your management choses to afford) understands.

    Man, how did I fuck that up?

    You could still get 12 characters worth of postcodes by interpreting the stored value as a number in base-36, and getting the values back out with % and /. log36 263 is about 12.19, so there's enough room in a 64-bit integer for 12 characters stored as base-36.

    Of course, if you're worried about 6-bit fields confusing people, wait till you break out the math...



  • @Fred Foobar said:

    You could still get 12 characters worth of postcodes by interpreting the stored value as a number in base-36, and getting the values back out with % and /. log36 263 is about 12.19, so there's enough room in a 64-bit integer for 12 characters stored as base-36.

    Of course, if you're worried about 6-bit fields confusing people, wait till you break out the math...

    Yes, but at least the operators you'll be using there are mostly ones with which they'll already be familiar.  % is the only one they'd need to look up.  As opposed to them needing to look up <<, >>, |, &, and possibly ~.  Now, it will also generate a smidgen more heat, and if your CPU is fricking ancient, it could even run slower (although not even I have a processor that old anymore.)  But somehow, I doubt either of those are concerns.

    Of course, they could still make it confusing as heck if they wanted to by writing that code inline each time they need it, with different comments each time, each of which mischaracterizes the code in a different way.

    (It would also be exceedingly confusing if you wrote it as a function to get digit 'n', rather than converting the int64 to a string, and the string to an int64.)


Log in to reply