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

151–160 of 262 posts

Re: Bugs in Hello World

#151

Post by masklinn »

onion2k wrote: post #20
bestouff wrote: post #2

Well that's precisely the mindset of C/C++. You have to think by yourself about everything that can go wrong with your code. And, man, lots of things can go wrong. I find more modern languages so much less exhausting to use to write correct code.

I find more modern languages so much less exhausting to use to write correct code. Modern languages do catch more programmer errors than C/C++, but the more general point is that there are "edge cases" (redirecting to a file isn't an edge case) that developers need to consider that aren't magically caught, and understanding the language you use well enough so as not to write those bugs is important. The more experien…

> Modern languages do catch more programmer errors than C/C++, but the more general point is that there are "edge cases" (redirecting to a file isn't an edge case) that developers need to consider that aren't magically caught, and understanding the language you use well enough so as not to write those bugs is important.

But GP’s point is that modern languages can surface those issues and edge cases, and try to behave somewhat sensibly, but even sometimes “magically” report the edge cases in question.

That’s one of the things which is very enjoyable (though sometimes frustrating) in Rust, the APIs were (mostly) designed such that you must acknowledge all possible errors somehow, either handling it or explicitly suppressing it.

Re: Bugs in Hello World

#152

Post by masklinn »

shultays wrote: post #101

Should "hello world" return error if it actually prints something but there was no person to read the output? Maybe the user was distracted and was not looking at the screen. Does a "hello world" program make sound if no one hears it? Sounds like the program failed its objective, greeting the world. And thus imho shouldn't return 0.

The program’s objective was to output the information, not to ensure that a user read it. Redirecting to `/dev/null` is a valid and common use of a program warranting no warning, so is running a program, collecting its log, then ultimately discarding it having never looked at it (in fact it’s the norm of well-behaved and solid programs).

Re: Bugs in Hello World

#153

Post by [deleted] »

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…

[deleted]

Re: Bugs in Hello World

#154

Post by pickledcods »

nojs wrote: post #55
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.

I think they are arguing that it didn’t fail, it did everything you asked of it (it didn’t claim to successfully print hello world in every scenario, just to attempt to write to the buffer you gave it, which it did).

The program failed to check the return value of the called function.

Re: Bugs in Hello World

#155

Post by pixelbeat__ »

mcbrit wrote: post #148
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". */

Jim Meyering's discussion on how this is handled usually in GNU programs

https://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodb...

Re: Bugs in Hello World

#158

Post by pickledcods »

Do not forget the notes on dup2(). It's about the automatic closing of newfd before it gets replaced. I've bumped into this situation several times, that is why I'm mentioning it.

  SYNOPSIS
   int dup2(int oldfd, int newfd);

  NOTES:
  If newfd was open, any errors that would have been reported at close(2) time are lost.
  If this is of concern, then the correct approach is not to close newfd before calling dup2(),
  because of the race condition described above.
  Instead, code something like the following could be used:

   /* Obtain a duplicate of 'newfd' that can subsequently
      be used to check for close() errors; an EBADF error
      means that 'newfd' was not open. */

   tmpfd = dup(newfd);
   if (tmpfd == -1 && errno != EBADF) {
       /* Handle unexpected dup() error */
   }

   /* Atomically duplicate 'oldfd' on 'newfd' */

   if (dup2(oldfd, newfd) == -1) {
       /* Handle dup2() error */
   }

   /* Now check for close() errors on the file originally
      referred to by 'newfd' */

    if (tmpfd != -1) {
       if (close(tmpfd) == -1) {
           /* Handle errors from close */
       }
   }

Re: Bugs in Hello World

#159

Post by moring »

knorker wrote: post #141
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.

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.

Re: Bugs in Hello World

#160

Post by usrbinbash »

Enjoyable read for sure, but i think the question whether ot not this constitutes a bug or not is open for interpretation.

IMHO, it doesn't.

hello.c is written in a way that makes it very clear that the program doesn't care about error conditions in any way shape or form; the return value of printf is ignored, the output isn't flushed, the return of flushing isn't checked, noone looks at errno; ...so anything happening that could go wrong will go unreported, unless its something the OS can see (segfault, permission, etc.)

If I expect a program to do something (eg. handle IO errors) that its code says very clearly that it doesn't, that's not the programs fault.

Post reply on HN