Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
Terry Lambert wrote: Stefan Farfeleder wrote: On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: From: Jacques A. Vidrine [EMAIL PROTECTED] The application is broken. You must only check errno if you get an error indication from the library call. errno is only meaningful after a syscall error. Wrong, counter-example: strtol(). Wrong; the standard specifies that the errno shall only be checked when the return value is -1. The exception in the strtol() case is only for presetting errno to 0 before you make the call, and making a check only following a -1 return. Wrong, strtol() can set errno in two cases, when the value is outside the range of representable values or when no conversion could be performed. In the former case it will either return LONG_MIN or LONG_MAX and set errno to ERANGE, in the latter case it will return 0 and set errno to EINVAL. The return value of -1 has thus no special meaning and if your strtol() implementation is standard compliant and you set errno to 0 prior to calling it as you should, errno will always be 0 after strtol() has returned -1. The only cases where there is a _potential_ error returned by strtol() is when it returns 0, LONG_MIN or LONG_MAX. The behaviour described here is for a strtol() compliant with the IEEE Std 1003.1-2001 standard. In strict ISO C, strtol() is not forced to set errno to EINVAL when no conversions could be performed, it only has to return 0. Moreover, the implementation may set errno to something even when the conversion was successful. So, in strict ISO C, errno is meaningful only if strtol() returns LONG_MIN or LONG_MAX. In any case, a return value of -1 does not mean anything for strtol(). Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
Wrong, strtol() can set errno in two cases, when the value is outside the range of representable values or when no conversion could be performed. well 'natch. it's trying to do math.h style hacks and overloads errno. iirc those sorts of things stem from V6/V7 on the PDP/11 when you may have had no FPU and 32 bit ops were library functions. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
Maxime Henrion wrote:
Terry Lambert wrote:
Wrong, counter-example: strtol().
Wrong; the standard specifies that the errno shall only be
checked when the return value is -1. The exception in the
strtol() case is only for presetting errno to 0 before you
make the call, and making a check only following a -1 return.
[ ... ]
The only cases where there is a _potential_ error returned by strtol()
is when it returns 0, LONG_MIN or LONG_MAX.
So check it only in those cases.
I don't see the problem with errno being set willy-nilly in a
library to multiple different values in implementing some standards
defined behaviour, so long as it's indicated correctly.
Moreover, the implementation may set errno to something
even when the conversion was successful. So, in strict ISO C, errno is
meaningful only if strtol() returns LONG_MIN or LONG_MAX.
You should write your code to expect that a 0 return is not
an error indicator, then.
You know, real hardware would SIGFPE...
In any case, a return value of -1 does not mean anything for strtol().
Which is irrelevent to the discussion about whether or not a
library is allowed to futz errno to non-0 any time it wants.
We all know that the *only* reason this issue arose is that somone
was writing bogus error checking code that did something like:
errno = 0;
(void)some_library_function_returning_neg_one_on_error();
if (errno != 0) {
printf( I should have checked my return value, but\n);
printf( standards documents and man pages confuse me.\n);
}
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
From: Stefan Farfeleder [EMAIL PROTECTED] errno is meaningful for syscalls after an error (the original message). The fact that other functions also dink with errno is not relevant to that statement. I read boyd's statement as a contradiction to Jacques' one (only after syscall error vs. after library call error). some libc functions do mangle errno, but only after an error. in my terse statement the intention was to affirm that errno is meaningless unless an error has ocurred (a syscall being the simplest case, while random other libc calls may behave in the same way). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
In message [EMAIL PROTECTED], boyd, rounin write s: From: Stefan Farfeleder [EMAIL PROTECTED] errno is meaningful for syscalls after an error (the original message). The fact that other functions also dink with errno is not relevant to that statement. I read boyd's statement as a contradiction to Jacques' one (only after syscall error vs. after library call error). some libc functions do mangle errno, but only after an error. in my terse statement the intention was to affirm that errno is meaningless unless an error has ocurred (a syscall being the simplest case, while random other libc calls may behave in the same way). Errno is undefined unless the relevant manual page states otherwise. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote: The application is broken. You must only check errno if you get an error indication from the library call. Sorry, but I don't see your point. I know when to check for errno. If you took the little illustrating program for a real life example of the use of errno, that's unfortunate :-) The problem is that the emulated/wrapped close from libc_r does not behave like the real one. libc_r is leaking some of its guts (the tricks it's doing with O_NONBLOCK, etc) in the interface. This is technically a bug. The fix was trivial. Regards, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Tue, 25 Nov 2003, Enache Adrian wrote: On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote: The application is broken. You must only check errno if you get an error indication from the library call. Sorry, but I don't see your point. I know when to check for errno. If you took the little illustrating program for a real life example of the use of errno, that's unfortunate :-) The problem is that the emulated/wrapped close from libc_r does not behave like the real one. libc_r is leaking some of its guts (the tricks it's doing with O_NONBLOCK, etc) in the interface. This is technically a bug. The fix was trivial. I don't see a bug. You don't check errno unless the return is -1. If the return is -1, then it must be because ret = __sys_close(fd) failed in which case errno will be set appropriately. Even so, there are other things to worry about aside from the fcntl to set the flags. The wrapped close also uses fstat(2) which can fail in ways not listed by close(2). -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Tue, Nov 25, 2003 at 04:46:24PM +0200, Enache Adrian wrote: On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote: The application is broken. You must only check errno if you get an error indication from the library call. Sorry, but I don't see your point. I know when to check for errno. If you took the little illustrating program for a real life example of the use of errno, that's unfortunate :-) The problem is that the emulated/wrapped close from libc_r does not behave like the real one. libc_r is leaking some of its guts (the tricks it's doing with O_NONBLOCK, etc) in the interface. This is technically a bug. The fix was trivial. Hello Enache, My point was that this is not technically a bug. According to IEEE Std 1003.1-2001 aka the Single Unix Specification Version 3 (``SUSv3'') aka POSIX, an application must not examine and interpret `errno' unless the library gives an error indication. There are some functions--- strtol and family, sysconf, others--- that have unusual, errno-preserving behavior. These are described individually in the appropriate section of the standard. For these and only these, you can set errno to 0 and check it immediately after the function call to see whether an error has occurred. I believe that includes all functions described in ISO/IEC 9899:1999 (``C99''), as well as some described only in SUSv3. `close' is not a part of C99, nor is it attributed the `unusual', errno-preserving behavior in SUSv3. (By the way, this exact topic was discuss at some length by the the Austin Common Standards Revision Group this past summer.) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
Stefan Farfeleder wrote: On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: From: Jacques A. Vidrine [EMAIL PROTECTED] The application is broken. You must only check errno if you get an error indication from the library call. errno is only meaningful after a syscall error. Wrong, counter-example: strtol(). Wrong; the standard specifies that the errno shall only be checked when the return value is -1. The exception in the strtol() case is only for presetting errno to 0 before you make the call, and making a check only following a -1 return. You cannot make assumptions about underlying implementations; they may be either system calls or library routines, and your application is not supposed to know or depend on which case prevails. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Sun, Nov 23, 2003 at 04:14:08PM +0200, Enache Adrian wrote:
$ cc close.c -o close ./close
0
0
$ cc close.c -lc_r -o close ./close
0
25
$ cat close.c
#include errno.h
main()
{
int fd = open(/dev/null, 1);
printf(%d\n, errno);
close(fd);
printf(%d\n, errno);
}
This confuses rather badly applications which assume errno is meaningful.
The application is broken. You must only check errno if you get an
error indication from the library call.
URL:http://www.opengroup.org/onlinepubs/007904975/functions/errno.html
IEEE Std 1003.1, 2003 Edition says, in part:
``The value of errno should only be examined when it is indicated to
be valid by a function's return value.''
Cheers,
--
Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
From: Jacques A. Vidrine [EMAIL PROTECTED] The application is broken. You must only check errno if you get an error indication from the library call. errno is only meaningful after a syscall error. it is also well known that stdio uses isatty(3) (or equivelant) that may set errno to ENOTTY. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: From: Jacques A. Vidrine [EMAIL PROTECTED] The application is broken. You must only check errno if you get an error indication from the library call. errno is only meaningful after a syscall error. Wrong, counter-example: strtol(). Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
In message: [EMAIL PROTECTED] Stefan Farfeleder [EMAIL PROTECTED] writes: : On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: : From: Jacques A. Vidrine [EMAIL PROTECTED] : The application is broken. You must only check errno if you get an : error indication from the library call. : : errno is only meaningful after a syscall error. : : Wrong, counter-example: strtol(). errno is meaningful for syscalls after an error (the original message). The fact that other functions also dink with errno is not relevant to that statement. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Mon, Nov 24, 2003 at 03:33:49PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Stefan Farfeleder [EMAIL PROTECTED] writes: : On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: : From: Jacques A. Vidrine [EMAIL PROTECTED] : The application is broken. You must only check errno if you get an : error indication from the library call. : : errno is only meaningful after a syscall error. : : Wrong, counter-example: strtol(). errno is meaningful for syscalls after an error (the original message). The fact that other functions also dink with errno is not relevant to that statement. I read boyd's statement as a contradiction to Jacques' one (only after syscall error vs. after library call error). If that's a misinterpretation, I'm sorry. Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
$ cc close.c -o close ./close
0
0
$ cc close.c -lc_r -o close ./close
0
25
$ cat close.c
#include errno.h
main()
{
int fd = open(/dev/null, 1);
printf(%d\n, errno);
close(fd);
printf(%d\n, errno);
}
This confuses rather badly applications which assume errno is meaningful.
It could be fixed easily by repeating the trick from uthread/uthread_fd.c:
--- /arc/freebsd/src/lib/libc_r/uthread/uthread_close.c Tue Jun 10 23:42:27 2003
+++ lib/libc_r/uthread/uthread_close.c Sun Nov 23 00:50:30 2003
@@ -87,10 +87,12 @@ _close(int fd)
*/
if ((S_ISREG(sb.st_mode) || S_ISCHR(sb.st_mode))
(_thread_fd_getflags(fd) O_NONBLOCK) == 0) {
+ int saved_errno = errno;
/* Get the current flags: */
flags = __sys_fcntl(fd, F_GETFL, NULL);
/* Clear the nonblocking file descriptor flag: */
__sys_fcntl(fd, F_SETFL, flags ~O_NONBLOCK);
+ errno = saved_errno;
}
/* XXX: Assumes well behaved threads. */
Regards,
Adi
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
