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

[stonemetal12]

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

[usrbinbash]

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.

[admax88qqq]

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

[usrbinbash]

Where did I say that?

I said if a software doesn't have a spec, the code IS the spec.

If I hand out a sheet of paper saying "the program returns X", but running it returns Y instead, the program is buggy.

If I hand out a piece of code which says "return X", and someone runs it expecting it to return Y, thats not the codes problem.

[ericHosick]

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.

[dancemethis]

Speak for yourself on the bus...

[parksy]

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?

[oneeyedpigeon]

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

[User23]

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.

[myrrlyn]

given that the sole purpose of software is to do what people want, "it didn't do what i want" is automatically incorrect behavior

[monkpit]

So that would mean as soon as your software has 2 users, it is broken because it doesn’t conform to their 2 (different) imaginary specs?

[thfuran]

Yes, unless you have a sufficiently complex and inscrutable EULA to point to as proof that at least one of the users was out of spec.

[rplnt]

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.

[shikoba]

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.

[ryandrake]

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.

[shikoba]

It depends. That kind of code does or doesn't disturb me in production code.

[bombcar]

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

[shikoba]

4. How to find if a function terminates

[hombre_fatal]

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.

[l33t2328]

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

[usrbinbash]

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.

[layer8]

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

[usrbinbash]

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 <stdio.h>` means,...

Sure, we could update it:

    // hello_v2.0.c
    #include <stdio.h>
    #include <string.h>
    #include <errno.h>

    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.

[nextaccountic]

This just demonstrates that C is an awful programming language for writing correct programs.

Compare this with Rust, where the usual hello world will just do the right thing:

    $ cat > a.rs
    fn main() {
        println!("Hello World");
    }
    $ rustc a.rs
    $ ./a            
    Hello World
    $ echo $?
    0
    $ ./a > /dev/full                                                                                                                                
    thread 'main' panicked at 'failed printing to stdout: No space left on device (os error 28)', library/std/src/io/stdio.rs:1187:9
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    $ echo $?                                                                                                                                     
    101

[dralley]

Or Zig which tries to make it easy to actually handle those errors.

[paavoova]

Your usage of errno can cause failure on success if errno was set any time before the call to fflush. Might need a bump to v3 for robustness...

[gpm]

According to cppreference

> The value of errno is 0 at program startup, and although library functions are allowed to write positive integers to errno whether or not an error occurred, library functions never store 0 in errno.

https://en.cppreference.com/w/c/error/errno

So this program correctly tests whether printf or fflush wrote to errno. You just can't refactor it into a function you call not at startup... I suppose that is unless you're keeping to a convention where you always set errno back to 0 after any call that might have set it...

[layer8]

This is much simpler:

  int n = printf("Hello, World!\n");
  return n < 0 ? EXIT_FAILURE : EXIT_SUCCESS;

[usrbinbash]

On my machine:

    $ cat main.c
    #include <stdio.h>

    int main(void) {
        int n = printf("Hello, World!\n");
        return n < 0 ? 1 : 0;
    }

    $ cc main.c
    $ a.out
    Hello, World!
    $ echo $?
    0
    $ a.out > /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 <unistd.h>

    int main(void) {
        int n = write(1, "Hello, World!\n", 14);
        return n < 0 ? 1 : 0;
    }

But even then, to find out what exactly went wrong, we would have to check errno.

It's easier in Go, because fmt functions do have an error return which will report such errors;

    func main() {
        _, err := fmt.Println("Hello, World!")
        if err != nil {
            os.Exit(1)
        }
    }

[layer8]

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 useful to demonstrate the necessary error handling, if any. The above is just showing that this is not entirely trivial in C with its standard library.

[Erwin]

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.

[usrbinbash]

> to give a taste of the respective programming language

The question is, how much of a taste? We could also include structs, manual memory management, pointers, macros, #ifdef guards; because these are all so very common to C programs, they are definitely part of the languages flavour.

Also, which of the error handling techniques in C should be included, because the language doesn't have a standard one, there are no exceptions or multiple returns. Even within the most basic libraries we have everything from checking global error states, inbound messenger variables, magic number returns, errorflags, ...

Again, hello.c is supposed to be simple. As simple as possible. Yes, that excludes a lot of things. These things are what all the other chapters of "The C Programming Language" are about.

As a starter, hello.c is great.