Live data from Hacker News

History's Worst Software Bugs (2005)

archive.wired.com

21–30 of 34 posts

Re: History's Worst Software Bugs (2005)

#21

The Soviet Gas Pipeline explosion - if the whole CIA story is true at all - should not be labelled a bug... The code allegedly did exactly what it's creator intended ;-)

Well, typically the users decide what is and isn't a bug. The developers can always say "I intended it to do this". ;)

Re: History's Worst Software Bugs (2005)

#22
post #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.

But gets() isn't just one unsafe function all of the classic string functions are totally unsafe, and most of their safer replacements are similarly bad. They do things like take buffer size and then will truncate strings and leave off the terminating zero. So then the next string function will blow up.

I think really when people manipulate strings in c/c++ they use the safe functions that come with frameworks.

Re: History's Worst Software Bugs (2005)

#24

Earlier quoted context omitted.

The obvious fix is to use a 64bit integer to hold timestamps.

That's the fix, of course, but what about all the embedded software that will last enough to cross that barrier but that won't be upgraded from its 32bits timestamps?

You'd have to find it, too. How many companies have manufactured devices with embedded software that have gone out of business, devices for which no manuals exist anymore, etc?

Re: History's Worst Software Bugs (2005)

#25
post #20

Seem 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…

Unit tests would be highly unlikely to catch most of those. "a formula written on paper in pencil was improperly transcribed", "neglect to properly "seed" the program's random number generator, A HW bug that's not close to obvious numbers to check, intentionally inserted bugs, input outside of the intended design, etc.

>"a formula written on paper in pencil was improperly transcribed"

offtopic, but a unit type would have prevented that. i had no idea how many errors i was making in my math programs before i started using F#'s type checker to make sure all the types lined up properly.

Re: History's Worst Software Bugs (2005)

#26
post #25
post #20

Earlier quoted context omitted.

Unit tests would be highly unlikely to catch most of those. "a formula written on paper in pencil was improperly transcribed", "neglect to properly "seed" the program's random number generator, A HW bug that's not close to obvious numbers to check, intentionally inserted bugs, input outside of the intended design, etc.

>"a formula written on paper in pencil was improperly transcribed" offtopic, but a unit type would have prevented that. i had no idea how many errors i was making in my math programs before i started using F#'s type checker to make sure all the types lined up properly.

I don't know the actual transcription error, but how's it going to find a 5 being made a 6 or something?

Re: History's Worst Software Bugs (2005)

#27
post #25

Earlier quoted context omitted.

>"a formula written on paper in pencil was improperly transcribed" offtopic, but a unit type would have prevented that. i had no idea how many errors i was making in my math programs before i started using F#'s type checker to make sure all the types lined up properly.

I don't know the actual transcription error, but how's it going to find a 5 being made a 6 or something?

it wont, but the vast majority of errors with math formulas are along the lines of adding velocities with positions, raising something to the wrong power, using a multiply instead of an add, putting a parenthesis in the wrong spot, performing equations in the wrong order, etc.

all of those can get caught with type checking, but it isn't perfect

Post reply on HN