Pet Bugs?

benreece asks: "During my few years as a programmer/developer I've come across some strange bugs. Recently I found that Microsoft's VB/VBScript(ASP) round function has problems (for example, 'round(82.845)' returns '82.84' instead of '82.85'). It took me an annoyingly long time to realize the problem wasn't mine. I'm wondering what other obscure, weird, and especially annoying bugs in languages/compilers/etc have frustrated other developers." Memorable bugs. Every developer has one. What were yours?

Comments

Re:That's what round SHOULD do

[Ed Avis]

I guess it depends on the documented behaviour of VB's round function. Anyone brave enough to wade through MSDN for it?

Re:From MSDN...

[pclminion]

They haven't changed anything. I was taught to round this way in the first science class I ever took. Scientists have rounded this way for at least a hundred years.

And it's for good reason: 2.5 is NOT closer to 3 than to 2. Neither 2 or 3 should be preferred, but we have to choose SOMETHING. Therefore the compromise is to round down when the rounding point is an even digit, and round up when it is odd. In the long run this cancels out the upwardly-drifting rounding error. You still introduce error (you're ROUNDING), but that error is equally distributed high and low, so the AVERAGE error is zero. The easy way to remember this is, when rounding off a 5, the result will always be even.

Also, the rint(), rintl(), and rintf() functions in glibc also round in this way.

Two days to deadline, lets add some security�

[Saggi]

Based on a true story!

A few years ago I was working as the lead programmer on a cd-rom game. Two days before deadline, the manager of the project decided that we should implement a copy protection.

Now you can see where it is going... right?

Well the manager had talked to the company who was going to print the cd-roms. They had this piece of software that would protect the system. All we had to do was to write a component that needed to be called in order to start the game. If this component weren't called at first the game wouldn't start. We thought about it for some time. As we only had two days, we decided to let the component write down an encoded string, based on the current date to the harddisk, and then inside the game, well hidden read the string and match the date. As I have coded the game I made the part inside the game, while an other developer made the start-up component. I designed the specification of the coded string. It contained a lot of crap, and well hidden, the two digits indicating the day.

Now I coded my part in such a way that it would work 4 days after the date. (Allowing me to more easily bypass midnight at the end of the month - especially February). This would hopefully also put off hackers, as the game would appear to be hacked, as the coded string would work for a few days.

We tested the system, especially the end of months, going from the 28-31st to the 1st. It was end of November, close to Christmas - therefore the hurry. Then the cd-roms went into print.

4 of December I received one of the first copies, just as the packages was prepared to be send out to the shops. I put it into the computer, and it failed... I tried again... and again. The way the program terminated looked subspecialty like the protection, so I started to look closely into what was happening. It was the date. 4 of December were a single digit. The protection component wrote 40 while the game looked for 04... My fellow developer had misunderstood the specifications. Of cause testing for 31 would work... it was two digits.

We trashed all the cd-roms and made a new version without protection. Our manager will probably not ask us to do such a change with such short notice an other time.

A thought thou; The cd-roms would have worked on Christmas eve... its two digits, but a new year... he he he.

In all seriousness, random libs *suck*

[edremy]

random() only returns 666 if you use a demon seed!

My favorite "bugs" are the truly horrible random number functions in almost every single language library on earth. They're usually linear congruential generators: fast, but utterly useless for any work that requires serious "randomness" such as Monte Carlo simulations. They have very short recurrence times, strong sequential correlation, etc.

Back in grad school, I had to substitute the Knuth ran3 routine for the supplied C library functions in both gcc and xlc since they were just awful.

Fast forward 8 years. I made the stupid assumption that since Java was a new language and that horrible problems with random number generators were well known that Sun would actually provide a decent RNG. Nope: just as badly flawed as the C one.

I suspect this is simply something to give up tilting at windmills about: random() is good enough for simple games and anyone doing real work knows to stay the hell away.

Re:Not a bug

[avalys]

Zero is rounded down? I suppose that's true, in the same sense that ten is rounded up.

Re:Not a bug

[Anonymous Coward]

Your reasoning is correct for numbers drawn from a continuous distribution, but in life, we usually have some end to our decimal representation. This is where the rounding bias is introduced. The fewer places of accuracy before rounding, the bigger the bias.

Consider the case in which you only have one digit of precision to the right of the decimal. Consider the set {0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9}. If you sum these numbers, you get 4.5. If you round using your method and then sum, you get 5. If you round using the "round down when the whole number part is even" method, you get 4. Each method has the same amount of error.

Now consider the set {0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.6, 1.8, 1.9}. If you sum *these* numbers, you get 19. If you round using the "5 always goes up" method and sum, you get 20. If you round using the "round down when the whole number part is even" method and sum, you get 19. One of these methods is not biased...

Re:True story

[demastri]

Actually, the true VB bug is turning incompetent weenies into programmers...