Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Can a software ever be 100% bug free?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Ask HN: Can a software ever be 100% bug free?

#11

Post by greenyoda »

wglb wrote: post #10
insoluble wrote: post #9

If we can agree that low-level hardware such as CPUs are essentially physical software, then it would seem that there are many bug-free software pieces out there. Many operating systems these days seem to have perfect or near perfect memory and thread management. Kernel mode drivers in general require a high level of quality since bugs usually mean death. User mode is where things get sloppy, and front-end Web Develo…

it would seem that there are many bug-free software pieces out there. I don't think that you can consider CPUs to be bug-free. Just to pick one, Intel got SYSRET wrong: https://blog.xenproject.org/2012/06/13/the-intel-sysret-priv...

And don't forget the famous Pentium division bug in the 1990s:

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

Re: Ask HN: Can a software ever be 100% bug free?

#12

Post by insoluble »

greenyoda wrote: post #11
wglb wrote: post #10

Earlier quoted context omitted.

it would seem that there are many bug-free software pieces out there. I don't think that you can consider CPUs to be bug-free. Just to pick one, Intel got SYSRET wrong: https://blog.xenproject.org/2012/06/13/the-intel-sysret-priv...

And don't forget the famous Pentium division bug in the 1990s: https://en.wikipedia.org/wiki/Pentium_FDIV_bug

I never said they were all bug-free. I am aware that there have been some problems over the years, but the track record seems much better with CPUs than with most things having what could be called advanced programming.

Re: Ask HN: Can a software ever be 100% bug free?

#14

Post by LukeShu »

S4M wrote: post #13

It depends of the complexity of the software. The small Unix utilities like grep or ls are, AFAIK, bug free, because what they do is very simple, but something more complicated is more likely to have small bugs somewhere.

There was a bug in ls, long ago; it stuck around long enough that it became a feature. It was supposed to not list "." or "..", but instead it skipped all files starting with "."; which thus became the standard way to hide a file on *nix.

Re: Ask HN: Can a software ever be 100% bug free?

#15

Post by AnimalMuppet »

tr352 wrote: post #6

You can mathematically prove whether a piece of code is 100% bug-free using formal verification techniques ( https://en.wikipedia.org/wiki/Formal_verification ). However, these techniques are often too computationally expensive in many practical cases. Moreover, formal verification requires one to very precisely specify how a piece of code should behave, as well as how the environment in which it operates may behave.…

And then you have the problem of proving that the specification is bug free...

Re: Ask HN: Can a software ever be 100% bug free?

#16

Post by Someone »

S4M wrote: post #13

It depends of the complexity of the software. The small Unix utilities like grep or ls are, AFAIK, bug free, because what they do is very simple, but something more complicated is more likely to have small bugs somewhere.

http://savannah.gnu.org/bugs/?group=grep: "48 matching items - Items 1 to 48"

https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=bs...: "15 bugs found."

Not all of these are bugs, but there definitely are bugs in populair implementations of grep.

Re: Ask HN: Can a software ever be 100% bug free?

#17

Post by chrisBob »

greenyoda wrote: post #11
wglb wrote: post #10

Earlier quoted context omitted.

it would seem that there are many bug-free software pieces out there. I don't think that you can consider CPUs to be bug-free. Just to pick one, Intel got SYSRET wrong: https://blog.xenproject.org/2012/06/13/the-intel-sysret-priv...

And don't forget the famous Pentium division bug in the 1990s: https://en.wikipedia.org/wiki/Pentium_FDIV_bug

The fact that the famous Pentium division bug is still being talked about speaks highly of processors as bug-free software.

Re: Ask HN: Can a software ever be 100% bug free?

#19

Post by wglb »

insoluble wrote: post #12
greenyoda wrote: post #11

Earlier quoted context omitted.

And don't forget the famous Pentium division bug in the 1990s: https://en.wikipedia.org/wiki/Pentium_FDIV_bug

I never said they were all bug-free. I am aware that there have been some problems over the years, but the track record seems much better with CPUs than with most things having what could be called advanced programming.

Having a game over user to kernel exploit available for who knows how long is not my idea of anywhere near bug-free.

And who knows what happens or what bugs are fixed when intel/amd push new firmware to the chip.

Re: Ask HN: Can a software ever be 100% bug free?

#20

Post by rnovak »

I think it can be formally proved that software that is non-trivial cannot be written to be 100% bug free in all cases, in all contexts, and I think that's a by-product of how software runs.

We have so many layers that software has to run on-top of: You have raw hardware, but a layer above that is the BIOS, and a layer above that is the OS, and a layer above that are the SDKs like .NET/GTK/Ncurses/Shell, and above that you have the layers that are built into software itself as abstractions, and on top of that ...

If anything on any one of those layers changes, you have the potential of introducing bugs. Not all interface contracts are honored by all developers/engineers. There have absolutely been cases where changes are made at one level and that has an effect on everything that runs on top of it.

So even if you can reliably say that your program is 100% bug free for a specific OS running on a specific set of hardware at Time T, that has the potential to break during the next release of any of those products.

The software the Patio11 mentions (NASA systems) is running in a very specific context. It's running on hardware that has a high level of formal verification, and it's running on a RTOS or running directly on hardware, such that there isn't anything that can interfere with the software, because otherwise even the CPU scheduler could introduce bugs into your system.

Anyway, that's my view of things, I'd love for someone to tell me if I'm wrong, since that's all based on observations I've made during my industry experience.

Post reply on HN