Hacker News Reader

Comment by boloust | Hacker News Reader

The bug is not that the program failed, it's that the program failed but reported a success.

Failure isn't defined by programmed control structures, it's defined by requirements and implemented via programming.

If the requirements of a hello world program include accounting for all error boundaries of the host system, then I am yet to see them written down but would invite anyone to provide them.

The parent comment has made a start in this regard.

This particular category of bug is something people - those making up the requirements too - probably wouldn't even consider.

Agreed. In a real world business requirements scenario, it would be dropped as premature optimisation if it was even considered at all.

And this is the reason unit tests are very often insufficient and provide vanishingly small value. They test programming details, while integration tests test requirements implemented via programming. Loved your first paragraph.

every program is given the 3 stdio channels: stdin, stdout, stderr. if the program is unable to use any of these as expected, it's an error that should be reported back to the user. today it's /dev/full but tomorrow it could be a log file with wrong access perms. you don't want to be returning 2 weeks later to find out that nothing was written, and your program didn't complain.

Agreed, the log file example is quite good, but also something like a systemd script reporting success when it actually failed.

This is true of *nix but on Windows they can be absent. In face this is the default for GUI applications.

To quote one of my favorite books:

  > [Hello, world] is the big hurdle. To leap over it you have to be able to
  > create the program text somewhere, compile it successfully, load it, run
  > it, and find out where your output went.

Those are the goals of "Hello, world!". Create the program, compile it, load it, run it, and find the output. Things that are not goals of "Hello, world!" are handling user input, reusable components (functions), network access, etc etc etc, error handling.

It's fine that the error is not handles, just as it is fine that the output went to stdout. Error handling was not a goal of the program.

I guess the argument is that the non-error-checking version fails at the "find out where your output went" stage. hello.c gives the impression that your output went to the file, even when it didn't.

Without a spec, I think it would be harsh to claim hello.c is wrong. But handling the error—in this case, returning it from main to the shell via an exit code—is definitely more correct.

> you have to be able to create the program text somewhere, compile it successfully, load it, run it, and find out where your output went.

Note that Rust "cheats" for you here, if you ask Cargo to make you a new Rust project then by default the project it gives you will perform Hello, World correctly when you "cargo run". It will also be version controlled (if Cargo can't figure out what type of version control you prefer, but git is installed, you get a git repo).

Rust's Hello World also of course panics if given a full output device. Because just ignoring errors by default, while very C, is not a good idea and in Rust it's much easier to respond to unexpected errors by just panicking rather than ignoring them.

> Those are the goals of "Hello, world!". Create the program, compile it, load it, run it, and find the output.

(Emphasis mine)

How are you going to find the output if there is an error outputting it and you're not capturing that?

Given the requirements you've given, that would absolutely make error handling mandatory in my opinion.

Interesting perspective, with which I happen to disagree. But I appreciate considering it, thank you.

I think they are arguing that it didn’t fail, it did everything you asked of it (it didn’t claim to successfully print hello world in every scenario, just to attempt to write to the buffer you gave it, which it did).

No, I think the argument was pretty clearly that "the program failed but it can't possibly be expected to work under every conceivable scenario".

It seems possible they are arguing:

    _exit(write(1,"Hello World!\n",13));

is the correct one, but to me that just kicks the can. What should happen here?

    os.rename(x,y)
    print("success!")

should this exit nonzero? The file did get renamed and progress was made, even if some unrelated problem occurs, so some animation for a users benefit who is probably dealing with some other problems thinking piping to /dev/full was a good idea in the first place, well, it just seems almost cruel to further burden them with a surprising error code, so maybe I should wrap that print line in a pokemon since the output doesn't really matter that much anyway.

So it is I prefer to think of bugs as the difference between expectation and reality, and I think it should be fair to say different users can be predisposed to have different expectations; So I also I think it matters a great deal what the contract/expectations are.

But I also know the difference between /dev/full and /dev/null

I think

   return printf("Hello, world!\n") < 0;

would suffice.

Edit : bugs are easy

The program failed to check the return value of the called function.

Well, if you want your hello world program to try to write Hello world, then report success regardless of the result, then it is bug-free. If you intend your program to write hello world on your screen/stdout, then it is definitely buggy.

The computer will do what you ask it to do, it's only a bug, when it doesn't meet your expectations.

Whether the program fails or not, is a matter of specification.

    printf("Hello, World!\n")

Is me saying: "Do a write syscall to stdout. I don't care what the return value is, I don't care if the flush is successfull if stdout happens to be buffered." If that is what I want to do, aka. what the program is specified to do, then it didn't fail.

To me, your example says: "I forgot about the return value." The way I learned C, if you really, really want to say "I don't care what the return value is" you'd explicitly cast it, nicely documenting your active non-caring about the return value for future code readers:

    (void) printf("Hello, World!\n");

Although, in general, ignoring the return value from things like puts() and printf() is a bad idea, for reasons the article makes clear.

And how do I explicitly ignore the other ways C communicates error conditions, like global error variables (eg. errno), inbound error values, errflags in structs?

Reply on news.ycombinator.com