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

171–180 of 262 posts

Re: Bugs in Hello World

#171

Post by Anthony-G »

avar wrote: post #123

A real world example of catching (some, but certainly not all) fflush(), ferror() etc. cases is what "git" does at the end of its execution, the first highlighted line is where it's returning from whatever function implements a built-in ("status", "pull", "log" etc. etc.): : https://github.com/git/git/blob/v2.35.0/git.c#L464-L483 Doing something similar would be a good addition to any non-trivial C program that emits…

I work as a sysadmin and only write the odd program/script (Python, Perl, Bash). In the past, I’ve run into the problem of not being able to write to a log file (disk full or insufficient permissions) so I now check for these situations when opening or writing to a file.

A while ago, I started learning C in my personal time and am curious about this issue. If `close()` fails, I’m guessing there’s not much else the program can do – other than print a message to inform the user (as in the highlighted git code). Also, I would have thought that calling `fsync()` on a file descriptor would also return an error status if the filesystem/block device is full.

Re: Bugs in Hello World

#172

Post by l33t2328 »

usrbinbash wrote: post #160

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

You shouldn’t have to read the code to understand what a program does, from an external POV at least.

Re: Bugs in Hello World

#173

Post by tialaramex »

masklinn wrote: post #151
onion2k wrote: post #20

Earlier quoted context omitted.

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…

Indeed. One of the things you notice when writing say, Advent of Code solutions in Rust is that you're writing unwrap() a lot e.g. something like

let geese = usize::from_str_radix(line.strip_prefix("and also ").unwrap().strip_suffix(" geese.").unwrap(), 10).unwrap();

All these functions, usize::from_str_radix, str::strip_prefix, str::strip_suffix are Options which could be None, and we need to decide what to do with that option, Option::unwrap() says I promise this is Some(thing) and I want that thing. If you're wrong and the Option was None, Rust will panic.

Sure enough sometimes while rushing to solve an AoC problem you may get told your program panicked because you tried to unwrap None. Oops, I wrote "geese" above and thus didn't handle the scenario where it might say "goose" in the input when there was only one of them... need to handle that properly.

In a C program taking the same approach it's easy to skip that unwrap() step. After all we're sure it's fine... aren't we? And in the absence of any error reporting now all you know is AoC says the answer you got was wrong and you've got no idea what the problem is.

Re: Bugs in Hello World

#174

Post by bombcar »

shikoba wrote: post #166
rplnt wrote: post #163

Earlier quoted context omitted.

So the question boils down to: Is hello world a program that is supposed to write hello world or is it a program that is supposed to (compile and) start? For me it's usually the latter.

None. Hello world is a program for beginners to teach them the most basic way to debug a program. The sole purpose of hello world is to explain how to print internal state of a program. In that case the examples are correct, they succeed.

Exactly. When you’re done with hello world you’ve solved some major problems:

1. How to store the code in a file

2. How to find and use the compiler and linker

3. How to run compiled code

Re: Bugs in Hello World

#175

Post by Perseids »

matheusmoreira wrote: post #168
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…

I also had higher expectations after reading the title and was disappointed when I realized it was about failure to handle all possible system call results. I thought it was gonna be a bug in the C standard library or something. I still agree with the author though. This is a serious matter and it seems most of the time the vast amount of complexity that exists in seemingly simple functionality is ignored. Hello worl…

And specifically no space left on device is a very common error that is also very commonly handled badly. Happened to me yesterday and the error messages I got were unhelpful or non-existent. In Firefox part of a website I was desperately trying to use just stopped reacting for some functionality. Developer tools opened as a blank space. Importing a calendar entry in Evolution produced an inscrutable SQLite error. Starting Chromium (as backup browser in the hopes that the website would work better there) via Gnome did not open any window or show any error. It was only when I tried to start Chromium via the console that I saw a helpful error message for the first time.

Also I always start to mildly panic in such cases, as lots of software corrupts its on-disk state more when the hard drive is full than any segfault, OOM-kill or hard shutdown is able to. I can understand and empathize on how this happens from a software development perspective, but objectively speaking "our entire field is bad at what we do, and if you rely on us, everybody will die". ( https://xkcd.com/2030/ )

Re: Bugs in Hello World

#176

Post by Thaxll »

moltenguardian wrote: post #7

Even Golang de facto suffers from this. I don't think I can name a time I saw someone check the return value of fmt.Print or log.Print. Not checking the return value still seems the the "right" thing to do.

Because fmt and log print are not usually not used for this, if I were to do it properly I would use io.Copy() which everyone check the result.

Checking the result of log and print is very tedious and not useful most of the time.

Re: Bugs in Hello World

#177

Post by bombcar »

shikoba wrote: post #169
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…

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

Re: Bugs in Hello World

#178

Post by dotancohen »

hnlmorg wrote: post #146
dotancohen wrote: post #58

Earlier quoted context omitted.

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.

Interesting perspective, with which I happen to disagree. But I appreciate considering it, thank you.

Re: Bugs in Hello World

#179

Post by User23 »

oneeyedpigeon wrote: post #167
usrbinbash wrote: post #160

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

This is a strange definition of 'buggy' to me. Surely it shouldn't depend on anything to do with the source code, otherwise closed-source programs are all 'neither-buggy-nor-not-buggy' and that can't be the case...

Most software is incapable of being incorrect, because correct behavior isn’t defined! Hence the questions here about who’s to say what’s correct. When the typical programmer says a program is “buggy” it means “it didn’t do what I want.” That’s a pleasantness property, not a correctness one.

Re: Bugs in Hello World

#180

Post by hombre_fatal »

shikoba wrote: post #166
rplnt wrote: post #163

Earlier quoted context omitted.

So the question boils down to: Is hello world a program that is supposed to write hello world or is it a program that is supposed to (compile and) start? For me it's usually the latter.

None. Hello world is a program for beginners to teach them the most basic way to debug a program. The sole purpose of hello world is to explain how to print internal state of a program. In that case the examples are correct, they succeed.

Of course, it’s also a way to show even experienced devs the most basic boilerplate to begin working from in something new.

What are the starting incantations and how do I run it.

Post reply on HN