undefined | Better HN

0 pointsusrbinbash4y ago0 comments

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.

0 comments

nextaccountic4y ago

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

dralley4y ago

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

paavoova4y ago

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

gpm4y ago

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

layer84y ago

This is much simpler:

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

usrbinbashOP4y ago

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

layer84y ago

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.

2 more replies

j / k navigate · click thread line to collapse

0 pointsusrbinbash4y ago0 comments

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

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.

0 comments

nextaccountic4y ago

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

dralley4y ago

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

paavoova4y ago

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

gpm4y ago

According to cppreference

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

layer84y ago

This is much simpler:

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

usrbinbashOP4y ago

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

layer84y ago

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.

2 more replies

j / k navigate · click thread line to collapse