Right now the printf(3) family of manpages make no reference to errno.
Glancing at __vfprintf, it appears that most of the erroneous paths do
set errno.

Should the manual be amended to reflect this behavior, so that users
have a documented way to determine the cause of failure in such cases?

Note this is a smaller concession than a full ERRORS section to
enumerate error codes, which would pin down the error API, making it
hard to change without user breakage. errno is still useful without
this section thanks to libc functions like strerror(3) and err(3).

The intended effect on userspace developers is to encourage picking
warn(3) over warnx(3) when logging, and other similar choices.


Index: lib/libc/stdio/printf.3
===================================================================
RCS file: /cvs/src/lib/libc/stdio/printf.3,v
retrieving revision 1.74
diff -u -p -u -r1.74 printf.3
--- lib/libc/stdio/printf.3     13 Oct 2015 12:25:04 -0000      1.74
+++ lib/libc/stdio/printf.3     5 Sep 2018 18:28:33 -0000
@@ -642,7 +642,9 @@ a field; if the result of a conversion i
 field is expanded to contain the conversion result.
 .Sh RETURN VALUES
 For all these functions if an output or encoding error occurs, a value
-less than 0 is returned.
+less than 0 is returned and the global variable
+.Va errno
+is set to indicate the error.
 .Pp
 The
 .Fn printf ,

Reply via email to