History's Worst Software Bugs (2005)
archive.wired.com
History's Worst Software Bugs (2005)
1–10 of 34 posts
Re: History's Worst Software Bugs (2005)
#2> Programmers respond by attempting to stamp out the gets() function in working code, but they refuse to remove it from the C programming language's standard input/output library, where it remains to this day.
gets was deprecated in C99 and removed in C11.
Re: History's Worst Software Bugs (2005)
#3> Programmers respond by attempting to stamp out the gets() function in working code, but they refuse to remove it from the C programming language's standard input/output library, where it remains to this day. gets was deprecated in C99 and removed in C11.
... but what percentage of current C code is C11. More importantly, how much new code is written according to C11?
Re: History's Worst Software Bugs (2005)
#4The title said "software", so I assumed they were going to exclude the infamous Pentium FPU bug. But no, there it is.
To me, the interesting thing about testing a CPU is that it's theoretically possible to comprehensively test all inputs and outputs, but the time required makes that totally impossible.
Re: History's Worst Software Bugs (2005)
#5Seem to me this list needs to incorporate how easily these bugs could have been avoided/detected/fixed, rather than just how dire the consequences were. It doesn't say much about what people did to test their code. For instance the first one in the list is something unit testing would have fixed. Take the trajectory function, plug numbers in, see if it's correct.
Some of these things were a lot more obvious than others.
Race conditions, for example, can be really hard to find, but as long as you know it might happen (these days it's just about every system) you can take precautions for testing. If it's important, maybe hire someone with experience.
The AT&T network crash thing looks pretty unobvious to me. A network graph can have a huge number of topologies, so you can't really test them all. Machines might also be using different versions of software that don't interact nicely. Sounds like they took sensible precautions and were thus able to roll back. That's why "rollback" is a word.
There's a whole class of bugs where things work and then need to be upgraded. You think it will work, because there aren't many changes and stuff is qualitatively the same. Like the number overflow bug in the Ariadne, or the buffer overflow in the finger daemon.
Re: History's Worst Software Bugs (2005)
#6No mention to Y2K and mankind can thank the millions of man/hours employed (and regally paid) to stamp out the majority of the occurrences of that bug.
It could really be a game changer if it didn't get fixed and I don't really know what expect in the wake of Y2K38 because it's about there, lurking in waiting.
Re: History's Worst Software Bugs (2005)
#7[deleted]
Re: History's Worst Software Bugs (2005)
#8> Programmers respond by attempting to stamp out the gets() function in working code, but they refuse to remove it from the C programming language's standard input/output library, where it remains to this day. gets was deprecated in C99 and removed in C11.
C11 is about 6 years newer than the article. So the article was accurate at the time it was written.
Re: History's Worst Software Bugs (2005)
#9Seem to me this list needs to incorporate how easily these bugs could have been avoided/detected/fixed, rather than just how dire the consequences were. It doesn't say much about what people did to test their code. For instance the first one in the list is something unit testing would have fixed. Take the trajectory function, plug numbers in, see if it's correct. Some of these things were a lot more obvious than othe…
The AT&T network crash bug was caused by a well-formed message coming from a crashed system, so that would have been caught by unit testing too.
Re: History's Worst Software Bugs (2005)
#10The title said "software", so I assumed they were going to exclude the infamous Pentium FPU bug. But no, there it is. To me, the interesting thing about testing a CPU is that it's theoretically possible to comprehensively test all inputs and outputs, but the time required makes that totally impossible.
Not so much anymore... there has been a ton of work put in by the EDA companies to get companies to do formal verification (which they obviously sell very expensive tools for) even before you get to physical design and testing.
For the chip my team is designing, we are formally verifying our ISA using a new domain specific language (http://www.cl.cam.ac.uk/~acjf3/l3/) which really helps lock down the "gold model" which all our other tests (Our cycle accurate C++ model, our RTL (verilog) model, and eventually the physical simulation) need to live up to.
As far as the tools provided by EDA companies, they have a ton of standard verification tools that have actually gotten a lot better and faster since the 90s, but best of all there are things like Cadence's Palladium (http://www.cadence.com/products/sd/palladium_series/pages/de...) which is basically a super FPGA like device which isbuilt specifically for verifying functionality of your circuits... while a FPGA is to 100 to maybe 1000x faster than simulating RTL, Cadence claims Palladium is up to 1,000,000x faster than RTL simulation.
Anyways: Most chips done today (especially due to the advanced process nodes) require EXTENSIVE verification that is just as long, if not longer, than the design and implementation (though it occurs at the same time as part of the "flow").