| |||||||||||||
GCC Explorer - an interactive take on compilationGCC Explorer - an interactive take on compilationPosted May 25, 2012 2:08 UTC (Fri) by ejr (subscriber, #51652)In reply to: GCC Explorer - an interactive take on compilation by Richard_J_Neill Parent article: GCC Explorer - an interactive take on compilation
This whole thread just shows that no one pays attention to return values or error conditions.
(Log in to post comments)
GCC Explorer - an interactive take on compilation Posted May 25, 2012 7:04 UTC (Fri) by cmccabe (guest, #60281) [Link]
gcc can see if you are using the return value or not and act appropriately. The gcc guys have been known to do some pretty boneheaded things (read some of Torvalds' rants), but blatantly violating the C standard by returning the wrong thing from printf is something I wouldn't expect even them to do.
More generally, most people opt not to check the return value of writing to stdout, because they just don't care. There's nothing really wrong with that. Now if you're writing to a file using fprintf, you should really be more careful. But I digress.
GCC Explorer - an interactive take on compilation Posted May 26, 2012 19:07 UTC (Sat) by ejr (subscriber, #51652) [Link]
A compiler cannot sanely know when errno is used. It's possible in some corner cases, but those aren't worth their time.
GCC Explorer - an interactive take on compilation Posted May 26, 2012 22:30 UTC (Sat) by cmccabe (guest, #60281) [Link]
That's true, but I don't think it's relevant here.
Both printf and puts will set errno when there is an error writing to stdout. The man pages (at least the ones I have installed) are oddly silent about this topic. However, once you realize that both of these functions just turn around and call write() eventually, and write() sets errno, the behavior becomes clear.
tl;dr: errno is a pretty crazy interface, but it's not really a problem here
GCC Explorer - an interactive take on compilation Posted Jun 3, 2012 16:29 UTC (Sun) by lacos (subscriber, #70616) [Link] most people opt not to check the return value of writing to stdout, because they just don't care. There's nothing really wrong with that.I disagree. stdout doesn't have to refer to a tty. It may have been redirected to a regular file. I'm not arguing that every single fprintf() retval should be checked. But at least fflush()'s retval and the error indicator of the output stream should be checked (with ferror()) at reasonable places.
GCC Explorer - an interactive take on compilation Posted Jun 6, 2012 9:26 UTC (Wed) by mpr22 (subscriber, #60784) [Link] I disagree. stdout doesn't have to refer to a tty. It may have been redirected to a regular file. That doesn't change the (lack of) importance to the program of whether printf("Now frobbing frob %d of %d (%s)\n", frob->num, total_frobs, frob->name); succeeds or fails.
GCC Explorer - an interactive take on compilation Posted May 25, 2012 7:36 UTC (Fri) by lindi (subscriber, #53135) [Link]
Return values are tricky indeed. LLVM had a bug where it converted printf to a putchar if you only printed one character. However if putchar failed it still returned 1:
http://llvm.org/bugs/show_bug.cgi?id=5104
|
|||||||||||||