This is (IMHO) the difference between unit testing and other testing.
Unit testing verifies it does what it is supposed to do ideally, and all other tests verify it can do it in non-ideal environments.
Bugs in Hello World
41–50 of 262 posts
Re: Bugs in Hello World
#42> There's our "No space" error getting reported by the OS, but no matter, the program silently swallows it and returns 0, the code for success. That's a bug! Bzzt, no. You can't say that without knowing what the program's requirements are. Blindly "fixing" a program to indicate failure due to not being able to write to standard output could break something. Maybe the output is just a diagnostic that's not important,…
> You can't say that without knowing what the program's requirements are.
The "program's requirements" can in theory be "to be buggy unusable piece of shit". But when we speak, we don't need to consider that use case.
Re: Bugs in Hello World
#43ok but how does one fix this bug in c or c++?
Re: Bugs in Hello World
#44Imo 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…
In this scenario you didn’t write any bytes though. You made a call to write to standard out (your process’s file handle 1) and didn’t succeed, you didn’t handle the possible error condition, you just silently ignored it.
I think this is pretty cut and dried - the failure is inside your process’s address space and the programmer error is that you haven’t handled a reported error.
>> what happens to the bytes AFTER the pipe?
There isn’t a pipe involved here, when your process was created it’s stdout was connected to dev/full then your program began executing
Re: Bugs in Hello World
#45I’m disappointed. I expected some obscure edgecase (like “Main is usually a function…” [1]) but instead that’s about scope handling, contract design and responsibility shift. “Hello world” method simply calls an API to a text interface. It uses simple call, to a simple interface that is expected to be ever present. I don’t find any bug there. It won’t work if such interface isn’t available, is blocked or doesn’t exis…
The bug is not that the program failed, it's that the program failed but reported a success.
Re: Bugs in Hello World
#46Earlier quoted context omitted.
This is true, however if we modify the program to print a 4096-byte long string instead of just the "hello world" string, then it's not sufficient again. And of course, the number 4096 is system-dependent. So to really do hello world in C right, in addition to fflush, you also need to check the return value from puts. I've never seen any C tutorial do that though.
What would be the expected reaction if either puts or fflush returns an error code? You might think, write a message on stderr (which may be different from stdout), but what if stderr is also redirected to a full device? How would you react to the error code returned from that? To me this is an indication that you need to know the context in which the program gets run, and its purpose in that context. Or you'd have t…
> What would be the expected reaction if either puts or fflush returns an error code? You might think, write a message on stderr (which may be different from stdout), but what if stderr is also redirected to a full device? How would you react to the error code returned from that?
I don't think you would react any differently on stderr failure unless you had a more complex system with alternate ways to report such things configured.
Just ignore it and continue to report the major error (stdout) in your exit status.
Re: Bugs in Hello World
#47In the end, it states that the language C has the bug. But this is wrong. In C, there are no exceptions, i.e. all error checking has to be explicit. This is just the language. So when you now ignore the error, this is not a bug of the language but just a bug in your code. The only thing you could argue is that this is a bad language design.
Or maybe this about global stdout object. With buffering enabled (by default), printf will not throw any error. The fflush would do. But a final fflush would be done implicitly at the end. But this is again all well documented, so still, this is not really a bug but maybe just bad language design.
I'm not exactly sure what C++ code was used. If this was just the same C code, then the same thing applies. And iostream just behaves exactly as documented.
Re: Bugs in Hello World
#48Curious if Zig's "software should be perfect" suffers from this.
It does not.
Re: Bugs in Hello World
#49#include
#include
int main(void) { if(puts("Hello, World!")!=EOF) { return EXIT_SUCCESS; }else { return EXIT_FAILURE; } }
Re: Bugs in Hello World
#50This raises an interesting question: is there any IO function that should return unit/void? Or equivalently are there any IO functions for which we can safely ignore the return value/ignore all exceptions? It seems like every single IO thing I can think of can have a relevant error, regardless of whether it's file-system related, network, or anything else.
In C, and many other languages, the file stream error state is saved after each operation, so you can skip error checking on every output line and only do if (fflush(stdout) != 0 || ferror(stdout) != 0) { perror("stdout"); return EXIT_FAILURE; } at the end of the program. The same should be done for stderr as well. In GNU programs you can use atexit(close_stdout) to do this automatically.
I wish this post were higher up, since it shows the idiomatic way to deal with that problem, unlike the article. Obviously the designers of the Unix i/o interface thought about this and provided for a simple way of handling it.