Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bugs in Hello World

blog.sunfishcode.online

Post reply on HN
Print view View original

231–240 of 262 posts

Re: Bugs in Hello World

#231

Post by karolist »

dylan604 wrote: post #228
karolist wrote: post #226

The author missed another bug, which many others do. You need a comma after Hello, as in "Hello, World!" because it's a direct address. Very, and I mean VERY few books get this right. 0. https://www.grammar-monster.com/lessons/commas_with_vocative...

Nah, it's an oxford comma.

Being a non-native speaker I had to look it up. Wikipedia says it's optional in British English but American English encourage, and sometimes mandate the use of it. If you look at https://commons.wikimedia.org/wiki/File:Hello_World_Brian_Ke..., which the author uses in their post - the comma's there. So why the inconsistency?

Re: Bugs in Hello World

#232

Post by sundarurfriend »

Julia (1.7) behaves pretty similar to the Python 2 one, a printed error related to closing the stream, and a 0 error code.

    ~ >>> julia -e 'print("Hello world")' > /dev/full
    error in running finalizer: Base.SystemError(prefix="close", errnum=28, extrainfo=nothing)
    #systemerror#69 at ./error.jl:174
    systemerror##kw at ./error.jl:174
    systemerror##kw at ./error.jl:174
    #systemerror#68 at ./error.jl:173 [inlined]
    systemerror at ./error.jl:173 [inlined]
    close at ./iostream.jl:63
    ⋮

    ~ >>> echo $?
    0
`errnum=28` apparently refers to the ENOSPC error: "No space left on device" as defined by POSIX.1; so the information is there, even if not in the most presentable form.

Re: Bugs in Hello World

#233

Post by dataflow »

jstanley wrote: post #142
dataflow wrote: post #116

Earlier quoted context omitted.

Yeah I should've said POSIX, my bad. But yeah my point was it's not plain C behavior. And yes on Linux I do see it with your no-op example now. Though for some reason not with 'head'... what's going on? Is it not closing the pipe when it exits? $ printf '%s\n' '#include ' '#include ' 'int main() { setvbuf(stdout, NULL, _IONBF, 0); int r = puts("Starting...\n"); r += fputs("First\n", stdout); fflush(stdout); usleep(10…

> it's not plain C behavior. But pipes aren't a C thing in the first place. "unistd.h" is not a C thing, file descriptors aren't a C thing.

The C program would just be using stdio to interact with pipes.

And not every platform with pipes supports SIGPIPE with such behavior.

Re: Bugs in Hello World

#234

Post by prewett »

/dev/full is brilliant, I need to remember that!

On the other hand, it's kind of depressing that I can't even write to stdout without needing to check for errors. And what are you going to do if that fails? Write to stderr? What if that fails because the program was run with `2>&1` ?

Re: Bugs in Hello World

#235

Post by winstonewert »

barrkel wrote: post #140
pron wrote: post #134

To those perplexed by the behaviour of Java's Hello World, as Java is otherwise very careful with error handling, this is because System.out is a java.io.PrintStream, and that's its documented behaviour:[1] > Unlike other output streams, a PrintStream never throws an IOException; instead, exceptional situations merely set an internal flag that can be tested via the checkError method. So the correct Hello World would…

It's a behavioural side-effect of checked exceptions. Because IOException is a checked exception, throwing it for console output would cause a lot of pain for printf debugging.

This interesting me because it shows that they had experience really early on in Java development that checked exceptions caused pain, and rather than realize that something was wrong with the design they started swallowing and ignore errors.

Re: Bugs in Hello World

#236

Post by ChrisSD »

yawboakye wrote: post #115
KnobbleMcKnees wrote: post #67

Earlier quoted context omitted.

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.

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

Re: Bugs in Hello World

#237

Post by deathanatos »

bombcar wrote: post #177
shikoba wrote: post #169

Earlier quoted context omitted.

> some other people disagree and say you should never use `set -e` outside of development I'm really interested. What are their arguments? And how do they handle errors?

See https://mywiki.wooledge.org/BashFAQ/105 for examples of side effects. I think the idea is you use set -e during development to find where you should catch errors, but in production you may want it off to reduce strange side-effects (or explicitly check for success in the way you expect; so not that the command returned 0 but that the file it made exists and is the right length, etc).

> but in production you may want it off to reduce strange side-effects

Having -e set is to reduce strange side-effects, by having the script fail, instead of plowing headlong into the land of undefined/unexpected behavior.

> See https://mywiki.wooledge.org/BashFAQ/105 for examples of side effects.

The `if` bit should be well-known if you're writing bash. The pipe bit is unfortunate, and is why -o pipefail is recommended, too. Or, just writing in a sane language that isn't going to page you in the middle of the night.

Re: Bugs in Hello World

#238

Post by dylan604 »

karolist wrote: post #231
dylan604 wrote: post #228

Earlier quoted context omitted.

Nah, it's an oxford comma.

Being a non-native speaker I had to look it up. Wikipedia says it's optional in British English but American English encourage, and sometimes mandate the use of it. If you look at https://commons.wikimedia.org/wiki/File:Hello_World_Brian_Ke... , which the author uses in their post - the comma's there. So why the inconsistency?

Yeah, I wasn't really serious seeing as the Oxford comma applies to a list of items. It's something that has never set well with me, the Oxford commma, as it makes the last item ambiguous when not present. So I now just throw out "Oxford comma" anytime there's a question on if a comma is needed or not.

Re: Bugs in Hello World

#239

Post by autoexec »

oneeyedpigeon wrote: post #137
mccorrinall wrote: post #13

Imo this is because the responsibility is not clearly defined and can be argued upon. If my program writes to the standard output, but you choose to redirect the pipe to a different location, is it my program’s responsibility to check what happens to the bytes AFTER the pipe? After all: my program did output everything as expected . The part which fucked up was not part of my program. I can see why some projects deci…

I feel like this is misrepresenting the article's point which isn't literally "hello world is buggy if it returns success on failure" but more "you should do error-handling". In this very specific case, you can argue that it's irrelevant. But if your program writes to a log file, or writes to a data file that it later reads from, it had better include some error-handling. The fact that there's redirection is a ... mi…

What's the real-life case where hello world fails because the file system is full?

You could do all kinds of things that would cause hello world to "fail". A broken monitor (or even one unplugged) wouldn't show "hello world" or give any indication of an error too, but it's hardly the codes fault. The code does what it's supposed to and ignores all kinds of other things that could go horribly wrong. That's not really a bug, just a known and expected limitation of the program's scope.

Re: Bugs in Hello World

#240

Post by oneeyedpigeon »

autoexec wrote: post #239
oneeyedpigeon wrote: post #137

Earlier quoted context omitted.

I feel like this is misrepresenting the article's point which isn't literally "hello world is buggy if it returns success on failure" but more "you should do error-handling". In this very specific case, you can argue that it's irrelevant. But if your program writes to a log file, or writes to a data file that it later reads from, it had better include some error-handling. The fact that there's redirection is a ... mi…

What's the real-life case where hello world fails because the file system is full? You could do all kinds of things that would cause hello world to "fail". A broken monitor (or even one unplugged) wouldn't show "hello world" or give any indication of an error too, but it's hardly the codes fault. The code does what it's supposed to and ignores all kinds of other things that could go horribly wrong. That's not really…

As I said, not hello world necessarily, but any program that writes output can encounter this problem, and there's an overlap with general file-writing even.
Post reply on HN