
The perils of relying on output streams in C (2011) [pdf] - cafebabe1991
https://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf
======
ploxiln
djb's old daemontools suite had an interesting solution to the "how to log
failure when you can't write to a log" problem: a persistent child process
with some space reserved in its argv, where it can stash some error messages
which you can see with "ps" even when disks have failed.

[http://cr.yp.to/daemontools/readproctitle.html](http://cr.yp.to/daemontools/readproctitle.html)

~~~
drefanzor
I still use this technique.

------
listprocess
for the corresponding text and video see--
[https://www.gnu.org/ghm/2011/paris/#sec-2-1](https://www.gnu.org/ghm/2011/paris/#sec-2-1)
and [https://audio-video.gnu.org/video/ghm2011/Jim_Meyering-
Goodb...](https://audio-video.gnu.org/video/ghm2011/Jim_Meyering-
Goodbye_World.ogv)

------
coliveira
printf and friends was not supposed to be robust, was supposed to be easy to
use. C already provides the means to write robust libraries, if that is
necessary.

~~~
chris_wot
Can you point me to how to do this?

~~~
coldnose
[https://linux.die.net/man/2/write](https://linux.die.net/man/2/write)

~~~
quietbritishjim
write() is part of Unix, not C.

------
renox
The "loosing the errno" issue seems to me easily avoidable: just save the
current value if ferror returns an error.

