6 ms·

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 writte

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.

rplnt 5y ago
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 5y ago
  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.
  - bombcar 5y ago
    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 5y ago
      4. How to find if a function terminates
  - hombre_fatal 5y ago
    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.
  - ryandrake 5y ago
    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 5y ago
      It depends. That kind of code does or doesn't disturb me in production code.
oneeyedpigeon 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        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.
- deleted 5y ago
  [deleted]
l33t2328 5y ago
You shouldn’t have to read the code to understand what a program does, from an external POV at least.
- usrbinbash 5y ago
  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.
stonemetal12 5y ago
>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 5y ago
  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 5y ago
    So if I don't write a spec, I have no bugs. Got it.
    - ericHosick 5y ago
      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 5y ago
        Speak for yourself on the bus...
    - usrbinbash 5y ago
      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.
- parksy 5y ago
layer8 5y ago
For didactic reasons it’s preferable to consider it a bug.
- usrbinbash 5y ago
  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 5y 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
    - dralley 5y ago

rplnt 5y ago

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 5y ago
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.
- bombcar 5y ago
  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 5y ago
    4. How to find if a function terminates
- hombre_fatal 5y ago
  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.
- ryandrake 5y ago
  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 5y ago
    It depends. That kind of code does or doesn't disturb me in production code.

oneeyedpigeon 5y ago

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 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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.
deleted 5y ago
[deleted]

l33t2328 5y ago

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

usrbinbash 5y ago
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.

stonemetal12 5y ago

>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 5y ago
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 5y ago
  So if I don't write a spec, I have no bugs. Got it.
  - ericHosick 5y ago
    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 5y ago
      Speak for yourself on the bus...
  - usrbinbash 5y ago
    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.
parksy 5y ago

layer8 5y ago

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

usrbinbash 5y ago
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 5y 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
  - dralley 5y ago