Slashdot Mirror
What is the Best Bug-as-a-Feature?
Bat Country wonders: "The workflow system, at the department I develop for, was hand-coded by my predecessor in a rather short amount of time, resulting in somewhat unreadable code with a number of interesting 'features.' When I took over maintenance of the code base, I started patching bugs and cleaning up the code in preparation for a new set of features. After I was done, I got a pile of complaints about features that had disappeared, which turned out to be caused by the bugs in the code. So, that leads me to ask: what is your favorite bug that you either can't live without or makes your life easier?"
buffer overflows are great - they allow you to get root on all sorts of devices that some bastard tried to lock you out of.
The famous undocmented 320x240 VGA video mode, pre-VESA, and other tweaked VGA modes.
I've heard the 6502 (or, more specifically, RP2A03) had some useful undocumented opcodes. I think they weren't intentional, so they might count.
On the software side...how about exploitable buffer overflows on the Xbox and PSP to enable execution of arbitrary code?
though Windows does this with flying (Blue) colors, I would nominate DRM. it screwed music and spurred development of P2P
- Minutus cantorum, minutus balorum, minutus carborata descendum pantorum.
As an engineer, I'm also amused.
4.0 is definitely a 2 sig dig number, but 4 could be 1 sig dig or it could be "exact." You wouldn't say the 2 in 2*pi*r is only one significant digit, would you? Of course not, it would render any precision in pi or r meaningless.
Also, 1200 could have 2, 4, or be exact depending on the context. It's best to always use a notation that includes the fraction mark for non-exact quantities.
Can you be Even More Awesome?!
If that isn't a bug, I don't know what is. That is because the IEEE standards for floating point values is the biggest and most prolific bug in software today.
Don't start modifing code until you understrand how the users use the product.
It is only refactoring if the users sees no change, with the sole exception of performance gains.
The Kruger Dunning explains most post on
The bacteria in my digestive tract are bugs I would definitely miss.
http://alternatives.rzero.com/
Not in programming, but in engineering.
Quite often calculations are performed where the various values are known to have a certain amount of uncertainty. If I take a reading of "4", what is really meant is that the value is between 3 and 5. If I specify "4.0", then the value is between 3.9 and 4.1. The amount of precision is given by the number of significant figures. Thus, a value of 4.0000 implies a fairly high degree of certainty.
Given that "4" has only a single significant figure, multiplying it by an exact 1200 yields 4800. However, if you round that off to a single significant figure, then the result is 5000.
As has been discussed already, however, the "4" may be exact, in which case you need to know the uncertainty in the "1200" before the uncertainty in the result of the calculation can be determined.
As a programmer, and a former student in at least one other math-related discipline, it's clear to me that 4 and 4.0 are equal. But they are not equivalent. Knowing 'Accuracy', 'Precision' and 'Proper Use Of Units' like the back of your hand will help you in any career.
[Ego]out
Nice. Perhaps having rm look at a filename called "-i" and interpret that as a command-line flag is probably the best "bug as feature" offered so far. :-)
"The human race's favorite method for being in control of the facts is to ignore them." -Celia Green
As a mathematician (or at least, an ex-mathematician) I am always amazed by mathematicians who forget that 'equality' between distinct domains is introduced (in standard developments) as a mere abuse of notation. Just because there is a canonical injection of Z into (say) Q does not mean that any element of Z is equal to any element of Q in any normal sense.
Moreover, since 4.0 is a floating point number, it's not even a very helpful abuse of notation to allow 4 and 4.0 to be 'mathematically' equal, since you can demonstrate that mathematically all floats are equal to each other: there's some nonzero epsilon small enough that epsilon + x is 'equal' to x. It is not helpful to then apply normal mathematical reasoning and conclude that all integers are equal - that is, it's nice to maintain some part of a programming language that is actually consistent, and if we're going to use the symbol '=' for both types, it's helpful at least to maintain that these are distinct overloads!
Really, any programming language for the mathematically savvy would issue a warning whenever you used a floating point type for anything; floating point support is a somewhat lame compromise for hardware compatibility. If on the other hand we had the habit of using constructive real numbers (which, unlike classical real numbers, are implementable), we would, quite rightly, be forced to reconsider the notion of equality globally.
Interesting that you're fixing a workflow system but you don't seem to have any of your own. What a developer considers bugs may not be considered bugs by the end users - and even if they are considered bugs, end users usually have work-arounds for them. If the bugs disappear, you've broken their work process. You may want to investigate collecting requirements and getting user buy-in before deciding to change their system. I've worked on systems where I've done something that I consider insignificant like changing the navigation, but the users didn't know that it was changing and started logging bugs, assuming something was broken.