ok but how does one fix this bug in c or c++?
`puts` has a return value indicating success or failure.
Bugs in Hello World
81–90 of 262 posts
Re: Bugs in Hello World
#82It's a good post, but heavily OS dependant. For example, on my Mac: $ ls /dev/null /dev/full ls: /dev/full: No such file or directory /dev/null I guess in theory, you can imitate `/dev/full` by other means.
I can't test this and the original blog post seems to be missing, but someone has a Github gist where they create a full ramdisk on OSX:
https://gist.github.com/koral--/12a6cdda22ffbd82f28ecc93e0b5...
Re: Bugs in Hello World
#83Earlier quoted context omitted.
Since macOS does not have /dev/full, I think what is actually happening here is your bash shell fails to create a file named "full" in "/dev" and so the bash shell exits with an error; this has nothing to do with node.js.
Yeah you are probably right. Now I'm curious about another interesting question. Should bash be the one that handle the error and exit code in this case? Since it seems to be responsible for handing the piping operation.
If by 'in this case' you mean the problem mentioned by the linked article, then no. The shell is not 'responsible for handling the piping operation'. It creates the pipe, but is not responsible for moving data through it.
Re: Bugs in Hello World
#84It's only a bug if the requirements are:
"Print Hello World and indicate if it succeed or not"
If the requirements were:
"Print Hello World, then return 0"
It's working as intended.
I'd even go so far as to say that print(); return 0; should always return 0, it would be weird for such a program to ever return anything other than 0 (where would that return come from?).
Re: Bugs in Hello World
#85Earlier quoted context omitted.
The bug is not that the program failed, it's that the program failed but reported a success.
Failure isn't defined by programmed control structures, it's defined by requirements and implemented via programming. If the requirements of a hello world program include accounting for all error boundaries of the host system, then I am yet to see them written down but would invite anyone to provide them. The parent comment has made a start in this regard.
This particular category of bug is something people - those making up the requirements too - probably wouldn't even consider.
Re: Bugs in Hello World
#86[deleted]
Re: Bugs in Hello World
#87You all joke that this doesn’t happen in practice, but something like this literally just bit me and it took me a few too many minutes to figure out what was going on. I use a bash script as my BROWSER which calls another bash script to launch or communicate with my browser that I run inside a container. The script that my BROWSER script calls has some debug output that it prints to stderr. I use mutt as my email cli…
> I use a bash script as my BROWSER which calls another bash script to launch or communicate with my browser that I run inside a container.
I'm not sure return codes are the source of your troubles...
Re: Bugs in Hello World
#88Since the article is being pedantic, here's another pedantic complaint: What if printf() can't write all of its output, but manages to write some of it? printf() returns the number of bytes written, but (and I'm sure someone will correct me if I'm wrong!) it doesn't guarantee to be atomic - it can't either write everything or nothing. Imagine a complicated printf() call with lots of parameters and long strings - some of it might get written, then the next write() that it does fails due to lack of space. What does printf() do then?
The article cites an example of writing a YAML file and the dangers of it being half-written. Well, you could imagine outputting a file all in one printf() with lots of %s's in the format string. Some get written, but not all. If printf() decides to return an error message, retrying the printf() later on (after deleting another file, say), will corrupt the data because you'll be duplicating some of the output. But if printf() just returned the number of bytes written, your program will silently miss the error.
So does 'Hello World\n' need to check that printf() succeeded, or does it actually need to go further and check that printf() returned 12? (or is it 13, for \r\n ?) I don't think there's any way to really safely use the function in real life.
Re: Bugs in Hello World
#89Imo this is because the responsibility is not clearly defined and can be argued upon. If my program writes to the standard output, but you choose to redirect the pipe to a different location, is it my program’s responsibility to check what happens to the bytes AFTER the pipe? After all: my program did output everything as expected . The part which fucked up was not part of my program. I can see why some projects deci…
> is it my program’s responsibility to check what happens to the bytes AFTER the pipe? No, but it's not "after". Rather, it's your responsibility to handle backpressure by ensuring the bytes were written to the pipe successfully in the first place. This isn't just about the filesystem being full btw. If you imagine a command like ./foo.py | head -n 10, it only makes sense for the 'head' command to close the pipe when…
What the pipe does is orthogonal to what the programme should do. The problem here is that errors are not being handled. There are languages such as rust that enforce error handling, whereby the policy on error is made explicit. The nuances you highlight are around what the errors should describe, which ultimately leads to more potential granularity in the error policy.
Re: Bugs in Hello World
#90Since we are going pedantic here, here are 3 bugs that I found in the blogpost: 1. Node.js result is out-dated. I run on Node.js v14.15.1 hello world code below on macOS and it reported exit code 1 correctly: // testlog.js console.log('hello world') process.exit(0) // bash $ node -v v14.15.1 $ node testlog.js > /dev/full -bash: /dev/full: Operation not permitted $ echo $? 1 2. Node.js is not a language. JavaScript is…
On node 16.9 console.log doesn't produce a non-zero exit code, but process.stdout.write does, and gives me a decent error message as well:
internal/fs/utils.js:332
throw err;
^
Error: ENOSPC: no space left on device, write
at writeSync (fs.js:736:3)