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.
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.
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.
> [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.
> 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.
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.
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).
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
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?
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.