Zip codes are not, strictly, numbers; and why this matters

I just sent — or, tried to send — this message to an online spice vendor via their contact form, after discovering that their order form treats zip codes as numbers.

Dear [vendor],

You have a serious problem on your web order form that will prevent anyone in New Hampshire, Massachusetts, Rhode Island, Maine, Vermont, Connecticut, New Jersey, or Puerto Rico from ordering from you, as well as any military personnel ordering via an APO.

You see, all these states/territories have zip codes with a leading zero.  Your site allows the correct zip code to be entered, but saves it as a number, not as a string.  That means you lose the leading zero.  My zip code, 03249, becomes 3429 er, 3249.  So when the site tries to match billing and delivery information against credit card billing address information for an order from one of these states, it will never match, because your stored zip code is wrong.

This error is costing you sales from seven states with a combined population of 23 million people.  I strongly suggest you may want to fix it.  (I was trying to order an 18oz jar of Hungarian hot paprika.  I won’t be able to order it from you, until and unless you fix this bug.  How many other sales have you lost this way?  Do you know?  Do you know you’re losing them?  How many abandoned shopping carts do you get per month?  How many of them are abandoned because of this bug?  These are questions you need to know the answers to.)

I say “tried”, because the contact form doesn’t work, insisting that you need to enable Javascript to send it.  (Javascript is enabled.)  They also urge you to “give us a call at [phone number]” if you “have a burning question you need the answer to right now”.  The only problem is, the number they urge you to call is listed elsewhere on the site as their FAX number.

Web store quality control FAIL.

Curses

Well, actually, it's not Curses.pm that's the problem.

As previously mentioned, I've been working on adding client-to-client encryption into ICBM, my threaded Perl ICB client.  I have session keys working in ICBM now, and needed to implement a way of reasonably securely exchanging session keys, which calls for Crypt::RSA.  So far, so good.

Crypt::RSA requires seven other modules for support.  OK, I can install those, though the module count is getting higher than I like.

One of those modules is Math::Pari, a Perl interface to the fast Pari math library.  OK, no problem.

Except that it is a problem, because Math::Pari in a multi-threaded Perl application, even if never used, causes SEGVs on the first thread termination.  Which means unclean exit and the app never gets to clean up after itself.  Apparently Math::Pari is very much not thread-safe.

Curses.  Foiled again...