[knorker]

> a hyperbole

It's not, though.

This helloworld is not safe to use as part of something bigger. Like:

    echo header > gen.txt && ./helloworld >> gen.txt && ./upload_to_prod gen.txt

That will upload a partial file to prod, if there's any write error.

> It's not meant to be part of a shell script

You don't know that. And brittle pieces like this is absolutely not an uncommon source of bugs.

[tgv]

> You don't know that

The first piece of C code in introduction section was meant as production software? I've checked it: that section mentions typing "a.out" in the the UNIX shell to see what happens.

[knorker]

Sorry, I'm not following. Introduction section of what?

[tgv]

The C programming language by Kernighan and Ritchie, the very source of hello world.

[knorker]

Lots of example code leaves out error handling alltogether. Not sure what your point is.

[moring]

If you don't know how the program is going to be used, how do you know that it is doing the right thing? Is "Hello world" actually the expected output?

Also, what makes the status code handling special compared to, say, - assuming the english language is the preferred language instead of asking the OS for the user's preference - assuming that the output has to be ASCII (or compatible) instead of something like UTF-16

There seems to be a weird obsession with the program's status code over anything else in this whole comment section, and it seems to me that the only reason for that is that back in the stone age of computing, the status code was the only thing that got standardized, while locale and encoding didn't, so properly supporting the latter is hard and therefore assumed to be less important.

[knorker]

> Is "Hello world" actually the expected output?

Isn't that the definition of helloworld?

> Also, what makes the status code handling special compared to, say, - assuming the english language is the preferred language instead of asking the OS for the user's preference - assuming that the output has to be ASCII (or compatible) instead of something like UTF-16

True. But by any definition printing nothing is a failure. If failing to print anything isn't a failure, what is?

> There seems to be a weird obsession with the program's status code over anything else in this whole comment section

It's because it's the only structured way to indicate success. And "not printing" is clearly a failure of "print 'hello world'".

> supporting the latter is hard and therefore assumed to be less important.

No, but printing nothing is clearly a failure. Printing the wrong language is not obviously a failure of helloworld, and absolutely not something helloworld can know on its own.

helloworld can know it failed to print what it intended to print. It cannot confirm that its intentions are correct, even in principle.

It cannot know whether some Lennartware has decided that anything built before yesterday (e.g. LANG envs and friends) can be ignored, and that in Lennart land all programs should write a request for the language to the blockchain, and wait for a reply transaction before printing anything.

Just because you can come up with examples of errors helloworld cannot check, doesn't mean that it should not do error handling for the things that it can.

`tar` cannot check that the user actually intended the particular file format flavor that it implements, but it can know that failing to write it should cause it to report an error.