I’m having a hard time seeing what is wrong with println actually checking for errors, unlike C in practice.https://twitter.com/myrrlyn/status/1170035475593064448 …
-
-
Replying to @pcwalton
In C it does, right? Just everybody ignores the return value of printf because there’s no reasonable recovery action.
1 reply 0 retweets 2 likes -
Sure there is, but the reasonable action depends on the program. Not on the stdlib deciding "oh, you should abort". Also, in C ignoring the return value of printf DOES NOT imply ignoring the error, since stdio errors are sticky. ferror(stdout) lets you see it later.
3 replies 1 retweet 10 likes -
Replying to @RichFelker @pcwalton
Totally agree, but I’ve yet to encounter a program that had a reasonable workaround to stdout writes failing. And you’re right that panic on this error in a library is just plain broken.
1 reply 0 retweets 1 like -
Every single C implementation of the standard posix utilities gets this right. Easiest way is just doing fflush and ferror before exiting, returning failure exit status if true. No need to check every call. gnulib automatically does it in gnu software.
1 reply 0 retweets 3 likes -
Replying to @RichFelker @pcwalton
Is non-zero exit for a printf failure appropriate? If a program is using stdout for status updates while it does some other op, maybe it completed its task successfully.
1 reply 0 retweets 0 likes -
For the std utilities, yes. In general, it depends on the program. This is why println panicing is such a bad design. If stdout is just informative and success/failure of the writes there have nothing to do with success/failure of the command, failure should be ignored.
2 replies 0 retweets 4 likes -
Replying to @RichFelker
I think I recall someone bringing this up at the time, but people were generally uncomfortable with ignoring errors without explicit intent by the programmer, as a general principle. Maybe that was the wrong decision, but the library was designed conservatively.
1 reply 0 retweets 0 likes -
Replying to @pcwalton
I think "ignoring an error that's a valid condition runtime condition, not a programming error" is a much more conservative behavior than "aborting the program". But making intent explicit is better than either.
2 replies 0 retweets 4 likes -
Replying to @RichFelker
Thinking about this, I can imagine cases in which ignoring errors could lead to security issues. HTML escaping or SQL injection come to mind. If some transient error causes a delimiter to not be printed for whatever reason, bad things could happen.
1 reply 0 retweets 0 likes
Granted, I don’t know if this is likely at all in practice.
-
-
Replying to @pcwalton
I think it's only an issue if subsequent writes can succeed, which shouldn't be possible.
1 reply 0 retweets 1 like -
Replying to @RichFelker @pcwalton
printf can EINTR and I doubt many programs handle that case
1 reply 0 retweets 0 likes - 5 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.