Puzzle: Transfering a hex number. Normally works, but very rarely arrives as the string “INF”. Why?

This was never going to work out. Data transfer interface. Our side in Perl and their side in PHP. Both scripting languages (bad) and not even the same scripting language (incompatible badness).

Over the data transfer interface, we are transferring users. Including a code to enable them to unsubscribe from an email newsletter. The first 7 characters of the code identify the users (digits) and the rest of the code is a hex string containing some security information.

All works great. But some users can't use the code? It turns out on the destination system they have "INF" in the field instead of the code.

It turns out that some of these users have e.g. 1234567 to identify the user, and e.g. 123e1234567 as their hex code. That makes the security code "1234567123e1234567". And that "looks like" a floating point number to Perl. But quite a big one. Almost as big as Infinity in fact, so might as well call it that.

I hardly think the flexibility we "won" through every data instance having its own type based on what its data "looks like" hardly compesnates the anger of a segment of our users not being able to unsubscribe from their newsletter, or the extra expense to the company of the time to debug this problem (which was then an urgent problem, as it was only discovered after the system went live, as it only affected 0.6% of our users).

P.S. my solution was to put a space in front of the code, which is taken off by the receiving system, so the data always "looks like" a string. But I wouldn't like to guarantee that what "looks like" a string won't change with the next version of the Perl SOAP client libraries we are using.

Update: See Explicit vs Implicit  Data Typing.