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

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

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

    $ 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

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;
    }

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

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.

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.