«
»

Spot the Bug Part 2

Another future exam question: Identify the intermediate programming error in the following screenshot from a major web standards organization:

28 March 2008: Basic XML Schema Patterns for Databinding Version 1.0 - Last Call Ends NaN

What likely happened here, and how could it have been avoided?

«
»

This entry was posted on Tuesday, April 1st, 2008 at 8:51 am and is filed under Programming. You can follow any responses to this entry through the Atom feed. Both comments and pings are currently closed.

6 Responses to “Spot the Bug Part 2”

  1. Daniel Spiewak Says:
    April 1st, 2008 at 12:18 pm

    “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.

  2. Semi Anonymous Says:
    April 1st, 2008 at 1:53 pm

    “Last Call Ends NaN”

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

  3. Bill Krueger Says:
    April 2nd, 2008 at 2:07 pm

    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.

  4. Gaurav Says:
    April 2nd, 2008 at 3:20 pm

    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.

  5. A. Openhim Says:
    April 4th, 2008 at 10:24 am

    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.

  6. Paul Says:
    April 9th, 2008 at 11:00 am

    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.