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

131–140 of 262 posts

Re: Bugs in Hello World

#131

Post by xelxebar »

HellsMaddy wrote: post #59

You all joke that this doesn’t happen in practice, but something like this literally just bit me and it took me a few too many minutes to figure out what was going on. I use a bash script as my BROWSER which calls another bash script to launch or communicate with my browser that I run inside a container. The script that my BROWSER script calls has some debug output that it prints to stderr. I use mutt as my email cli…

Interesting bug you found!

It sounds our sensibilities are similar regarding cli and tool usage. This is a side note, but as someone who used to use "Bash strict mode" in all my scripts, I'm now a bit bearish on `set -e`, mainly due to the subtle caveats. If you're interested, the link below has a nice (and long) list of potentially surprising errexit gotchas:

https://mywiki.wooledge.org/BashFAQ/105

(The list begins below the anecdote.)

Re: Bugs in Hello World

#132

Post by usrbinbash »

pjerem wrote: post #114
parker78 wrote: post #84

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

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 cal…

> 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.

Re: Bugs in Hello World

#133

Post by terinjokes »

ksbrooksjr wrote: post #90
paradite wrote: post #51

Since we are going pedantic here, here are 3 bugs that I found in the blogpost: 1. Node.js result is out-dated. I run on Node.js v14.15.1 hello world code below on macOS and it reported exit code 1 correctly: // testlog.js console.log('hello world') process.exit(0) // bash $ node -v v14.15.1 $ node testlog.js > /dev/full -bash: /dev/full: Operation not permitted $ echo $? 1 2. Node.js is not a language. JavaScript is…

On node 16.9 console.log doesn't produce a non-zero exit code, but process.stdout.write does, and gives me a decent error message as well: internal/fs/utils.js:332 throw err; ^ Error: ENOSPC: no space left on device, write at writeSync (fs.js:736:3)

This is because console.log isn't the equivalent to the post's printf. It is purposefully opaque to the application (and applications should not assume anything happens with the input).[0]

> Its main output is the implementation-defined side effect of printing the result to the console.

[0]: https://console.spec.whatwg.org/#logger

Re: Bugs in Hello World

#134

Post by pron »

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 be:

    System.out.println("Hello World!");
    if (System.out.checkError()) throw new IOException();
While the behaviour of PrintStream cannot be changed (it goes back to Java 1.0, and I'm guessing that the intention was not to require handling exceptions when writing messages to the standard output), adding a method to obtain the underlying, unwrapped OutputStream might be an idea worth considering, as it would allow writing to the standard output just like to any file.

[1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base...

Re: Bugs in Hello World

#135

Post by secondcoming »

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.

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

Re: Bugs in Hello World

#136

Post by oneeyedpigeon »

dotancohen wrote: post #58
boloust wrote: post #45

Earlier quoted context omitted.

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

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 com…

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.

Re: Bugs in Hello World

#137

Post by oneeyedpigeon »

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 ... misdirection. The redirection is only used to proxy a real-life case that can happen even when no redirection is taking place.

Re: Bugs in Hello World

#138

Post by tialaramex »

dotancohen wrote: post #58
boloust wrote: post #45

Earlier quoted context omitted.

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

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 com…

> 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.

Re: Bugs in Hello World

#139

Post by ale42 »

I was expecting Free Pascal not to have the bug, as Pascal generally fails with a visible runtime error, as it does I/O checking by default. However, it seems not to do it when WriteLn goes to the standard output... (even if it is then piped to /dev/full). So the basic

    begin
    WriteLn('Hello World!');
    end.
definitely has the bug, at least with the fpc implementation. On the other hand, explicitly trying to write to /dev/full from the Pascal source triggers a beautiful message:

    Runtime error 101 at $0000000000401104

Re: Bugs in Hello World

#140

Post by barrkel »

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.
Post reply on HN