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

211–220 of 262 posts

Re: Bugs in Hello World

#211

Post by Erwin »

layer8 wrote: post #207
usrbinbash wrote: post #206

Earlier quoted context omitted.

On my machine: $ cat main.c #include int main(void) { int n = printf("Hello, World!\n"); return n /dev/full $ echo $? 0 Problem is, printf is buffered. When redirecting to /dev/full writing to the buffer works. The problem only manifests when the buffer is flushed. This works, as write is not buffered; #include int main(void) { int n = write(1, "Hello, World!\n", 14); return n But even then, to find out what exactly…

I was expecting that printf would auto-flush at the newline, but either it doesn’t, or doesn’t report an error? An explicit fflush would probably work. In any case, hello world examples are used for two purposes, (a) providing a simplest possible program that you can run (with an indication that it worked), and (b) to give a taste of the respective programming language. At least for the latter case, it would be usefu…

The file objects in the library can operate as unbuffered, line-buffered or fully (i.e. block) buffered. When your stdout is connected to a terminal, it is line-buffered and flushes on newline. But when you redirect to a file, it becomes block buffered.

Re: Bugs in Hello World

#213

Post by ryandrake »

usrbinbash wrote: post #120
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.

Whether the program fails or not, is a matter of specification. printf("Hello, World!\n") Is me saying: "Do a write syscall to stdout. I don't care what the return value is, I don't care if the flush is successfull if stdout happens to be buffered." If that is what I want to do, aka. what the program is specified to do, then it didn't fail.

To me, your example says: "I forgot about the return value." The way I learned C, if you really, really want to say "I don't care what the return value is" you'd explicitly cast it, nicely documenting your active non-caring about the return value for future code readers:

    (void) printf("Hello, World!\n");
Although, in general, ignoring the return value from things like puts() and printf() is a bad idea, for reasons the article makes clear.

Re: Bugs in Hello World

#214

Post by Ericson2314 »

This is good. All the people questioning the spec need to realize is handling the error should be opt-out, not opt-in.

#[must_use] in Rust is the right idea: Rust doesn't automatically do anything --- there is no policy foisted upon the programmer --- but it will reliably force the programmer to do something about the error explicitly.

Re: Bugs in Hello World

#215

Post by Sohcahtoa82 »

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.

C/C++ basically do only exactly what you tell them and nothing more, which is why they're so much faster than other languages.

There's no garbage collection/reference counting/etc. going on in the background. Objects aren't going to be moved around unless you explicitly move them around (Enjoy your heap fragmentation!). In C, you don't even get exceptions.

Of course, this creates TONS of foot-guns. Buffer overflows, unchecked errors, memory leaks, etc. A modern language won't have these, except for memory leaks, but they're much less likely to happen in trivial to moderate complexity apps.

Re: Bugs in Hello World

#216

Post by ryandrake »

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.

I think a lot of people are getting too hung up on the fact that the application is specifically "hello world." The code is clearly buggy, even if you don't particularly care about bugs in this specific application. The author would have been better off not mentioning "hello world" as the application and simply said:

Find the bug!

    puts("This is a log");
I think everyone can agree that the above should be considered a bug in any kind of non-hello-world production code, for the reason the article mentioned.

Re: Bugs in Hello World

#217

Post by dfox »

matheusmoreira wrote: post #210
dfox wrote: post #209

Earlier quoted context omitted.

Userspace should not expect that any given syscall can only return some set of known errno values. You should enumerate the cases where you want to do some kind of special handling (with EINTR being somewhat more important that other cases) and have path to somehow handle even unexpected errno values. Both Linux man pages and SUS specify some set of possible error situations, but not all of them. In the man pages cas…

You're right. The manual contains this ominous notice at the very end of the errors section: https://man7.org/linux/man-pages/man2/write.2.html > Other errors may occur, depending on the object connected to fd. I don't understand why every possible result isn't explicitly documented. This is the Linux system call interface, we need to know everything that could happen when we make these calls.

The right assumption is that every syscall can return any defined errno value. In practice this means that you should handle the cases that you have to handle (-EINTR and for write(2) incomplete writes, which are typical reason for “fatal error: Success”), that you can somehow handle (things like retries for -ENOSPC) and log strerror(3) result for anything that you don't expect (whether you shoult then abort(), exit() or continue depends on how critical the failed syscall was).

Re: Bugs in Hello World

#218

Post by admax88qqq »

usrbinbash wrote: post #197
stonemetal12 wrote: post #183

Earlier quoted context omitted.

>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. Is there no such thing as a bug then? The program does what the code says so every "misbehavior" and crash is expected behavior.

There is a difference between a program with a specification/documentation outlining what it should do, and one that doesn't have a spec. AFAIK, hello.c doesn't have a spec, so the code is the spec. If I am using it, I have to read the code to know what it does.

So if I don't write a spec, I have no bugs. Got it.

Re: Bugs in Hello World

#219

Post by parksy »

stonemetal12 wrote: post #183
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…

>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. Is there no such thing as a bug then? The program does what the code says so every "misbehavior" and crash is expected behavior.

If we're going to reductio ad absurdum then OS's shouldn't let programs run if they interact with a device and don't explicitly handle exceptions for those devices. The OS is just a program and if it allows programs to crash it, isn't that the OS's fault?

Re: Bugs in Hello World

#220

Post by ericHosick »

admax88qqq wrote: post #218
usrbinbash wrote: post #197

Earlier quoted context omitted.

There is a difference between a program with a specification/documentation outlining what it should do, and one that doesn't have a spec. AFAIK, hello.c doesn't have a spec, so the code is the spec. If I am using it, I have to read the code to know what it does.

So if I don't write a spec, I have no bugs. Got it.

This Porsche has a design flaw: I can only go 22,500 kilometers before I have to replace the tires.

This VW bus has a design flaw: I can't pull more than 1G on the race track.

Post reply on HN