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

191–200 of 262 posts

Re: Bugs in Hello World

#191

Post by knorker »

tgv wrote: post #189
knorker wrote: post #141

Earlier quoted context omitted.

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

> You don't know that The first piece of C code in introduction section was meant as production software? I've checked it: that section mentions typing "a.out" in the the UNIX shell to see what happens.

Sorry, I'm not following. Introduction section of what?

Re: Bugs in Hello World

#193

Post by tgv »

knorker wrote: post #191
tgv wrote: post #189

Earlier quoted context omitted.

> You don't know that The first piece of C code in introduction section was meant as production software? I've checked it: that section mentions typing "a.out" in the the UNIX shell to see what happens.

Sorry, I'm not following. Introduction section of what?

The C programming language by Kernighan and Ritchie, the very source of hello world.

Re: Bugs in Hello World

#194

Post by shikoba »

bombcar wrote: post #174
shikoba wrote: post #166

Earlier quoted context omitted.

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

4. How to find if a function terminates

Re: Bugs in Hello World

#195

Post by usrbinbash »

layer8 wrote: post #185
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…

For didactic reasons it’s preferable to consider it a bug.

hello.c is meant as the first program a new student encounters when learning C. At that point, the student has enough to worry about; writing code to a file, checking for syntactic errors, basic program structure, using the compiler, executing the binary, understanding what `#include ` means,...

Sure, we could update it:

    // hello_v2.0.c
    #include 
    #include 
    #include 

    int main(void) {
        printf("Hello, World!\n");
        fflush(stdout);
        if (errno != 0) {
            fprintf(stderr, "error: %s\n", strerror(errno));
            return errno;
        }
    }
But now we have different libraries, a multitude of external identifiers, control structures, blocks, return values, the concept of buffered streams, the concept of file-descriptors, the printf formatting language, program return values, boolean logic & conditionals,...

To someone who is already experienced in another language, that may not seem like a big deal, and isn't, but to someone who encounters the language for the first time, this is heavy stuff.

Re: Bugs in Hello World

#196

Post by usrbinbash »

l33t2328 wrote: post #172
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.

If the program comes with a specification then yes, ideally that should be the case.

If there isn't one however, then the code is all there is.

Re: Bugs in Hello World

#197

Post by usrbinbash »

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.

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.

Re: Bugs in Hello World

#198

Post by hwinked »

I don’t think this is a bug. The program writes to stdout which is guaranteed by *ix to be there. If it is full, it would block until the kernel serviced it. In your examples, the user asked the shell to redirect to a full file and it reported the error.

Re: Bugs in Hello World

#200

Post by barrkel »

pron wrote: post #162
barrkel wrote: post #140

Earlier quoted context omitted.

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.

Well, Java has since introduced RuntimeIOException, which could be used in cases where an IO exception is unexpected, so we could introduce a new class, say, ErrorCheckingPrintStream, and add the method `ErrorCheckingPrintStream withErrorChecks()` to PrintStream if it's considered sufficiently worthwhile. So you could have: System.out.withErrorChecks().println("Hello World!); But we can't change the behaviour of the…

I think you mean UncheckedIOException - https://docs.oracle.com/javase/8/docs/api/java/io/UncheckedI...

RuntimeIOException from Jira has an amusing (and incorrect, IMO) message:

https://docs.atlassian.com/software/jira/docs/api/7.6.1/com/...

    > An IOException was encountered and the stupid programmer didn't know 
    > how to recover, so this got thrown instead.
It's a misguided doc comment because "recovering" from error is usually the wrong thing to do - usually the right thing is to abort whatever action is taking place, whether it's a request handler, event loop or standalone program. Situations like low disk space, incorrect file permissions, missing files and so on usually can't be recovered deep in the stack or without manual intervention.
Post reply on HN