121–130 of 262 posts
Seems like PHP does something reasonably right for once! $ php hello.php > /dev/full $ echo $? 255 It doesn't exactly print an error, but at least it returns something non-zero.
Earlier quoted context omitted.
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.
Would perror() return the first/oldest error or the last?
Doing something similar would be a good addition to any non-trivial C program that emits output on stdout and stderr.
In practice I haven't really seen a reason to exhaustively check every write to stdout/stderr as long as standard IO is used, and fflush() etc. is checked.
A much more common pitfall is when dealing with file I/O and forgetting to check the return value of close(). In my experience it's the most common case where code that tries to get it wrong actually gets it wrong, I've even seen code that checked the return value of open(), write() and fsync(), but forgot about the return value of close() before that fsync(). A close() will fail e.g. if the disk is full.
I’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…
Earlier quoted context omitted.
That's a POSIX thing. It doesn't apply to all C implementations but it does apply to many more than just Linux-based ones. You've not got a closed pipe so you wouldn't see it, you've just got a closed file descriptor. Try running it as ./a.out | : and you will probably see it. I say probably because there is a timing aspect as well, the write may happen before the pipe gets closed in which case it will not fail, but…
Yeah I should've said POSIX, my bad. But yeah my point was it's not plain C behavior. And yes on Linux I do see it with your no-op example now. Though for some reason not with 'head'... what's going on? Is it not closing the pipe when it exits? $ printf '%s\n' '#include ' '#include ' 'int main() { setvbuf(stdout, NULL, _IONBF, 0); int r = puts("Starting...\n"); r += fputs("First\n", stdout); fflush(stdout); usleep(10…
a) a.out writes line 1
b) a.out writes line 2
c) head reads line 1
d) head closes the pipe
We know that b and c both happen after a, and that d happens after c. However, we do not know whether b happens before c, between c and d, or after d. Your a.out process will only get killed by SIGPIPE if it happens after d.
On my system, running a.out under strace is enough to slow it down enough to affect the timing and see the SIGPIPE you were expecting. You may alternatively insert artificial delays in your test program such as by calling the sleep() function between the two lines of output to see the same result.
Earlier quoted context omitted.
Yeah I should've said POSIX, my bad. But yeah my point was it's not plain C behavior. And yes on Linux I do see it with your no-op example now. Though for some reason not with 'head'... what's going on? Is it not closing the pipe when it exits? $ printf '%s\n' '#include ' '#include ' 'int main() { setvbuf(stdout, NULL, _IONBF, 0); int r = puts("Starting...\n"); r += fputs("First\n", stdout); fflush(stdout); usleep(10…
That would be the timing aspect of it. You have: a) a.out writes line 1 b) a.out writes line 2 c) head reads line 1 d) head closes the pipe We know that b and c both happen after a, and that d happens after c. However, we do not know whether b happens before c, between c and d, or after d. Your a.out process will only get killed by SIGPIPE if it happens after d. On my system, running a.out under strace is enough to s…
printf '#include \nint main() { return printf("Hello world!\\n") && fflush(stdout); }\n' | cc -xc - && ./a.out > /dev/full && echo "Success\!"Earlier quoted context omitted.
> 2. Node.js is not a language. JavaScript is a language, This criticism is the wrong way around. All of the author's "languages" are actually language implementations like NodeJS. You can tell because he produced the results by running the code, rather than by reading a spec.
Yes you are right about the differences. So what I'm proposing is to put JavaScript in the language column (like other languages such as Java) and note the usage of Node.js as the implementation in the second column together with version (similar to Java -> openjdk 11.0.11 2021-04-20). Would that make sense?
It'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?).
The requirement of a "Hello World" program is always, by nature, to print "Hello World". If my program calls your Hello World program, it expects it to print Hello World. That's basically the point of the program. If your program don't print Hello World for whatever reason, of course you don't need to manage the error if it wasn't specified. But it's probably a bad thing (call it a bug or not) to exit 0 which the cal…
It'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.