Is there no such thing as a bug then? The program does what the code says so every "misbehavior" and crash is expected behavior.
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.
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.
This VW bus has a design flaw: I can't pull more than 1G on the race track.
Find the bug!
puts("This is a log");
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
What are the starting incantations and how do I run it.
If there isn't one however, then the code is all there is.
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.
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.
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.