Comments on: Spot the Bug Part 2

By: Paul

Paul — Wed, 09 Apr 2008 16:00:35 +0000

I used to work at a financial company where null values were not handled properly in the Java / XML conversion. The end result? If your last name was “Null”, your application had to be processed manually.

To this day, the bug still exists. With SOA, it would cost too much to change the apps to properly handle it.

By: A. Openhim

A. Openhim — Fri, 04 Apr 2008 15:24:53 +0000

I think they are using a date and then a float for the interval before the “last call”. They then attempt to do date arithmetic themselves.

By: Gaurav

Gaurav — Wed, 02 Apr 2008 20:20:39 +0000

Someone was trying to save a few bytes by storing the date in a float
They wrote their own function to convert this representation into a Date String that used floating point arithmetic.
This is a classic example of people who think they are writing efficient code – who in the process write code that is buggy and impossible to maintain.

By: Bill Krueger

Bill Krueger — Wed, 02 Apr 2008 19:07:04 +0000

Seems like someone was using a float (or double) to do non-floating point value handling (maybe using the different parts of the float to represent two independent integers) which eventually lead to a representation that wasn’t a real floating point number. Silly them. To avoiding things like this teach the developers about IEEE floating point number representation.

By: Semi Anonymous

Semi Anonymous — Tue, 01 Apr 2008 18:53:24 +0000

“Last Call Ends NaN”

I would guess that this has something to do with leap year

By: Daniel Spiewak

Daniel Spiewak — Tue, 01 Apr 2008 17:18:12 +0000

“Last Call Ends NaN”

Probably caused by a division by zero or similar. Best way to avoid would be to debug the code better next time. Alternatively, just perform a few minor checks or modify the Float -> String conversion to test for NaN and have a sane default.