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?
You know the kind. When you add in debug they go away.
We have a spider that comes crawling around our cubes every now and then. We don't kill him, figuring he helps keep the other bug populations inside down. We call him our little web developer.
I'm serious.
-Pete
Soccer Goal Plans
this has to be the most memorable one.
it's in the Linux man file
BUGS
Never use this function. This function modifies its first argument. The identity of the delimiting character is lost. This function cannot be used on constant strings.
The buttons below were pretty cool too. One said "ok" and the other one said "lame!"
If you clicked the lame! button, you just got to fill out a little comment card, but the feature cracked me up the first couple times I saw it.
I remember discovering __LINE__ and __FILE__ when I was doing some perl debugging. It was handy to do stuff like:
do(something()) or die("Failed on line " . __LINE__);
Of course, then I had this idea of using a debugging function (this is before I knew of warn,croak,carp, et al). So I happily wrote my function
sub debug { die("Failed on line " . __LINE__); }
And then spent hours trying to figure out why my code always failed on line 78, which happened to be where the debug() function lived. D'oh!
ID-10-T is a way of life
What's next - random() always returning 666 no matter what seed you use?
random() only returns 666 if you use a demon seed!
cpeterso
Back in the day when I used to program in C++, I was also really into making little ascii-art comments in my code. One time I had some code that looked like this:
#include <stdio.h>
// tom 7 was here - 1998 \\
typedef unsigned char uchar;
int something(uchar c);
...
(In actuality, the code was longer and more complicated, so it wasn't so easy to figure out...). Can you see the bug?
I was trying to debug a CMOS standard-cell chip that I designed in the late 80's. The bug was elusive, only showing up occasionally and I'd written various test routines to ferret it out. I started to suspect it was something to do with the PCB layout, so I was cutting and pasting tracks. Suddenly all the test routines worked perfectly and I thought GOTCHA! My mind was almost blown when I realized that I had inadvertently cut the power trace to the chip - it was working perfectly when Vcc wasn't connected!
Of course, I eventually figured out that the original problem was ground bounce and that with Vcc disconnected, the chip was getting power through the protection diodes on the control lines and bus. The lower voltage was slowing down the edges and reducing the ground bounce so that it worked correctly. I eventually solved the problem with PCB layout changes and the chip started working with Vcc connected!
Look, it's trying to think - Albert Rosenfield
If they had a sense of humour, they would have shipped version 1.0999999.
Accountability on the heads of the powerful.
Power in the hands of the accountable.
A common problem was that the heads on the hard drive would get stuck, and the machine would cease to operate. The standard operating procedure to remedy this was told to me as:
If that didn't work, secondary protocol was to remove the hard drive from the machine, place it on the desk, and hit it three or four times with the blunt end of a screwdriver.
According to the techs, this worked about 90% of the time.
Still, with a plan, you only get the best you can imagine. I'd always hoped for something better than that. -CP
The other strategy is to use "Arthur Andersen Rounding" which rounds all figures up to and including 3,800,000,000.00 to zero.