4 ms·
>If I expect a program to do something (eg. handle IO errors) that its code says very clearly that it doesn't, that's not the programs fault. Is there no such
by stonemetal12 5y ago
>If I expect a program to do something (eg. handle IO errors) that its code says very clearly that it doesn't, that's not the programs fault.
Is there no such thing as a bug then? The program does what the code says so every "misbehavior" and crash is expected behavior.
- usrbinbash 5y agoThere is a difference between a program with a specification/documentation outlining what it should do, and one that doesn't have a spec. AFAIK, hello.c doesn't have a spec, so the code is the spec. If I am using it, I have to read the code to know what it does.
- admax88qqq 5y agoSo if I don't write a spec, I have no bugs. Got it.
- ericHosick 5y agoThis Porsche has a design flaw: I can only go 22,500 kilometers before I have to replace the tires. This VW bus has a design flaw: I can't pull more than 1G on the race track.
- dancemethis 5y agoSpeak for yourself on the bus...
- usrbinbash 5y agoWhere did I say that? I said if a software doesn't have a spec, the code IS the spec. If I hand out a sheet of paper saying "the program returns X", but running it returns Y instead, the program is buggy. If I hand out a piece of code which says "return X", and someone runs it expecting it to return Y, thats not the codes problem.
- parksy 5y agoIf we're going to reductio ad absurdum then OS's shouldn't let programs run if they interact with a device and don't explicitly handle exceptions for those devices. The OS is just a program and if it allows programs to crash it, isn't that the OS's fault?