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

141–150 of 262 posts

Re: Bugs in Hello World

#141

Post by knorker »

tgv wrote: post #17

It's a fun take, but a hyperbole nonetheless. hello.c is supposed to be run from a terminal and write back to it: there's always space to write. It's not meant to be part of a shell script, so the error status is irrelevant. It does show that we take such examples a bit too literally: our feeble minds don't consider what's missing, until it's too late. That's a didactic problem. It only matters to certain kinds of so…

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

Re: Bugs in Hello World

#142

Post by jstanley »

dataflow wrote: post #116
hvdijk wrote: post #112

Earlier quoted context omitted.

That's a POSIX thing. It doesn't apply to all C implementations but it does apply to many more than just Linux-based ones. You've not got a closed pipe so you wouldn't see it, you've just got a closed file descriptor. Try running it as ./a.out | : and you will probably see it. I say probably because there is a timing aspect as well, the write may happen before the pipe gets closed in which case it will not fail, but…

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.

Re: Bugs in Hello World

#143

Post by LadyCailin »

xlii wrote: post #32

I’m disappointed. I expected some obscure edgecase (like “Main is usually a function…” [1]) but instead that’s about scope handling, contract design and responsibility shift. “Hello world” method simply calls an API to a text interface. It uses simple call, to a simple interface that is expected to be ever present. I don’t find any bug there. It won’t work if such interface isn’t available, is blocked or doesn’t exis…

Sounds like we need to use https://github.com/Hello-World-EE/Java-Hello-World-Enterpris... to cover all our bases.

Re: Bugs in Hello World

#144

Post by nebulous1 »

xlii wrote: post #32

I’m disappointed. I expected some obscure edgecase (like “Main is usually a function…” [1]) but instead that’s about scope handling, contract design and responsibility shift. “Hello world” method simply calls an API to a text interface. It uses simple call, to a simple interface that is expected to be ever present. I don’t find any bug there. It won’t work if such interface isn’t available, is blocked or doesn’t exis…

My initial take was the same as yours. However, I would be of the opinion that the program would definitely be better if it returned non-zero on failure, so the question for me is whether it rises to the level of "bug" or not. In retrospect I can't think of when I wouldn't consider a program silently failing to not be a bug (unless specifically designed to silently fail), so I've come round to agreement with the article.

Re: Bugs in Hello World

#145

Post by yesenadam »

I couldn't see GNU Hello mentioned in the article or comments so far. I wonder how it fares bug-wise.

The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.

However, unlike the minimal version often seen, GNU Hello processes its argument list to modify its behavior, supports greetings in many languages, and so on. The primary purpose of GNU Hello is to demonstrate how to write other programs that do these things; it serves as a model for GNU coding standards and GNU maintainer practices.

https://www.gnu.org/software/hello/

Re: Bugs in Hello World

#146

Post by hnlmorg »

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…

> Those are the goals of "Hello, world!". Create the program, compile it, load it, run it, and find the output.

(Emphasis mine)

How are you going to find the output if there is an error outputting it and you're not capturing that?

Given the requirements you've given, that would absolutely make error handling mandatory in my opinion.

Re: Bugs in Hello World

#147

Post by ketzu »

ketzu wrote: post #104
pdw wrote: post #70

Earlier quoted context omitted.

Well, I'd say that the older languages mostly get it right, while the newer languages mostly fail.

I am not sure either follows. But it depends how we even define "older languages", especially considering differences between python 3 and 2, are they the same age (based on the original python release) or are they treated for their respective release version? Just taking some simple release dates [1] or wikipedia I found: Ages of "Yes" group: 49, 36, 22, 26, 26, 12, 31 Ages of "No" group: 11, 14, 33, 7, 32, 45, 26,…

Aparently I copy-pasted the wrong link:

[1] https://iq.opengenus.org/age-of-programming-languages/

Re: Bugs in Hello World

#148

Post by mcbrit »

yesenadam wrote: post #145

I couldn't see GNU Hello mentioned in the article or comments so far. I wonder how it fares bug-wise. The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it. However, unlike the minimal version often seen, GNU Hello processes its argument list to modify its behavior, supports greetings in many languages, and…

This is explicitly called out and handled in lines 151-155.

https://git.savannah.gnu.org/cgit/hello.git/tree/src/hello.c

Here's the comment:

  /* Even exiting has subtleties.  On exit, if any writes failed, change
     the exit status.  The /dev/full device on GNU/Linux can be used for
     testing; for instance, hello >/dev/full should exit unsuccessfully.
     This is implemented in the Gnulib module "closeout".  */

Re: Bugs in Hello World

#149

Post by masklinn »

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…

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

The pipe is your standard output. Your very program is created with the pipe as its stdout.

> After all: my program did output everything as expected. The part which fucked up was not part of my program.

But you are wrong, your program did not output everything as expected, and it failed to report that information.

Re: Bugs in Hello World

#150

Post by kikoreis »

nemetroid wrote: post #93
jll29 wrote: post #79

Earlier quoted context omitted.

#include int main(void) { return !(puts("Hello, new world!") == EOF); /* return 0 unless a rare I/O error occurs */ }

First off, main should return 0 on success, not 1. Second, puts() will happily return 0 when writing to /dev/full.

Only if the write is buffered, right?
Post reply on HN