[parker78]

It's only a bug if the requirements are:

"Print Hello World and indicate if it succeed or not"

If the requirements were:

"Print Hello World, then return 0"

It's working as intended.

I'd even go so far as to say that print(); return 0; should always return 0, it would be weird for such a program to ever return anything other than 0 (where would that return come from?).

[hgomersall]

In your pseudocode, "Print Hello World" doesn't come with any caveats, like "unless there is an error, in which case silently don't print Hello World". If an error might occur, your description is incomplete if you don't describe the policy that should be taken.

Your second point might be fine, except that it doesn't describe the API that languages actually use to print. For sure, it's trivial to implement the policy you describe, but suggesting that everyone always needs that policy is rather limiting and makes light of the real bugs that failure to handle errors actually results in.

[pjerem]

The requirement of a "Hello World" program is always, by nature, to print "Hello World".

If my program calls your Hello World program, it expects it to print Hello World. That's basically the point of the program.

If your program don't print Hello World for whatever reason, of course you don't need to manage the error if it wasn't specified. But it's probably a bad thing (call it a bug or not) to exit 0 which the caller will interpret by "Hello World have just been printed successfully", I can go on and print ", John".

I agree it's probably not going to be in the requirements, and world will probably not collapse if you don't manage the error, but it's with no doubt an idiom required by most OSes to ensure programs are normally working.

You can also create orphan processes if it's needed by your requirements, but it's probably a bug or a hole in your requirements. Because at some point, non idiomatic programs will be used in situations where they will be creating issues. And we are talking about issues that are very hard to even spot.

Those "non requirements" are exactly how you lately discover that you have no logs from the last two weeks or that your backups aren't complete.

It's not requirement, but it's just hygiene.

tbf, I'm arguing of what should be an idea world, but I probably have myself written those sorts of bugs. Writing idiomatic code is hard and no one is to blame for not doing it perfectly. I just think it's some ideal to aim for.

[cowl]

But you are forgetting where to print. The classic "Hello World" program requires you to Print to a terminal not to a file. The fact that the terminal and a file can be used interchangeably in *nix system is not the responsibility of the program. Likewise, Printing "hello world" to my 3d printer is not the purpose either. My "hello world" program is meant to Assure the minimum possible feedback that the toolchain is working as expected and being called by your program is not a part of that purpose.

[usrbinbash]

> That's basically the point of the program.

The point of hello.c is to serve as demonstration to students of the language of what a very basic program looks like, and how to use the toolchain to get it to run.

That's it, that's the requirements specified.

[dmurray]

The interesting case for me is if the requirements were "print Hello World". I'd argue that the one with an explicit return value is incorrect in that case, because the extra line of code leads you to believe an extra requirement exists which is to indicate success.