| Message ID | 20171222193101.3396-3-aurelien@aurel32.net |
|---|---|
| State | New |
| Headers | show |
| Series | | expand |
On Fri, Dec 22, 2017 at 08:31:00PM +0100, Aurelien Jarno wrote: > The current glibc manual is ambiguous about the errno value on success > and suggests that it is left unchanged. Some functions might and > sometimes do change the errno value, however they never set it to 0. The trailing part "however they never set it to 0" is not quite correct: the next patch in the series moves "__set_errno (0)" around. The patch looks OK, please commit.
On Fri, Dec 29, 2017 at 03:46:54PM +0300, Dmitry V. Levin wrote: > On Fri, Dec 22, 2017 at 08:31:00PM +0100, Aurelien Jarno wrote: > > The current glibc manual is ambiguous about the errno value on success > > and suggests that it is left unchanged. Some functions might and > > sometimes do change the errno value, however they never set it to 0. > > The trailing part "however they never set it to 0" is not quite correct: > the next patch in the series moves "__set_errno (0)" around. Sorry, my example doesn't apply, but do we really guarantee they never set errno to 0?
On Dez 29 2017, "Dmitry V. Levin" <ldv@altlinux.org> wrote: > Sorry, my example doesn't apply, but do we really guarantee they never > set errno to 0? POSIX requires it, so we better make sure. Andreas.
On Fri, Dec 29, 2017 at 02:21:28PM +0100, Andreas Schwab wrote: > On Dez 29 2017, "Dmitry V. Levin" <ldv@altlinux.org> wrote: > > > Sorry, my example doesn't apply, but do we really guarantee they never > > set errno to 0? > > POSIX requires it, so we better make sure. OK then.
* Dmitry V. Levin: > On Fri, Dec 29, 2017 at 03:46:54PM +0300, Dmitry V. Levin wrote: >> On Fri, Dec 22, 2017 at 08:31:00PM +0100, Aurelien Jarno wrote: >> > The current glibc manual is ambiguous about the errno value on success >> > and suggests that it is left unchanged. Some functions might and >> > sometimes do change the errno value, however they never set it to 0. >> >> The trailing part "however they never set it to 0" is not quite correct: >> the next patch in the series moves "__set_errno (0)" around. > > Sorry, my example doesn't apply, but do we really guarantee they never > set errno to 0? Some of the NSS functions set errno to zero to indicate that the lookup was successful, but did not yield any results. There are applications out there which rely on this behavior because they do not set errno to 0 before calling the affected function (and pwd/tst-getpw.c indirectly checks for this behavior). This is bug 21898. I'm not sure if we can fix this without introducing new symbol versions.
diff --git a/ChangeLog b/ChangeLog index c8157a4e43..8368b3006d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2017-12-22 Zack Weinberg <zackw@panix.com> + + [BZ #22615] + * manual/errno.texi (Checking for Errors): Explicitly say that errno + might be set on success. + 2017-12-22 Aurelien Jarno <aurelien@aurel32.net> [BZ #22611] diff --git a/manual/errno.texi b/manual/errno.texi index 3e0b862c4e..73272fd884 100644 --- a/manual/errno.texi +++ b/manual/errno.texi @@ -47,20 +47,20 @@ However, a properly written signal handler saves and restores the value of @code{errno}, so you generally do not need to worry about this possibility except when writing signal handlers. -The initial value of @code{errno} at program startup is zero. Many -library functions are guaranteed to set it to certain nonzero values -when they encounter certain kinds of errors. These error conditions are -listed for each function. These functions do not change @code{errno} -when they succeed; thus, the value of @code{errno} after a successful -call is not necessarily zero, and you should not use @code{errno} to -determine @emph{whether} a call failed. The proper way to do that is -documented for each function. @emph{If} the call failed, you can -examine @code{errno}. - -Many library functions can set @code{errno} to a nonzero value as a -result of calling other library functions which might fail. You should -assume that any library function might alter @code{errno} when the -function returns an error. +The initial value of @code{errno} at program startup is zero. In many +cases, when a library function encounters an error, it will set +@code{errno} to a non-zero value to indicate what specific error +condition occurred. The documentation for each function lists the +error conditions that are possible for that function. Not all library +functions use this mechanism; some return an error code directly, +instead. + +@strong{Warning:} Many library functions may set @code{errno} to some +meaningless non-zero value even if they did not encounter any errors, +and even if they return error codes directly. Therefore, it is +usually incorrect to check @emph{whether} an error occurred by +inspecting the value of @code{errno}. The proper way to check for +error is documented for each function. @strong{Portability Note:} @w{ISO C} specifies @code{errno} as a ``modifiable lvalue'' rather than as a variable, permitting it to be