On Tue, Mar 02, 2004, Jordan K. Hubbard wrote: > That gives us this behavior for our little test program: > > errno = 13, rc = -1 > fwrite errno = 13, rc = 0 > > In both cases, we get EACCES for fputs() or fwrite() attempts on a > read-only file pointer pointing to a read-only device, something we'd > expect to get "permission denied" for I think.
Nice catch. I think the wording of POSIX suggests that the error code is supposed to be EBADF, which is returned if ``the file descriptor [...] is not a valid file descriptor for writing.'' Although you could argue that the standard is wrong, Linux and Solaris return EBADF, so we probably should, too. (By the way, there are a few other cantwrite() calls in libc that probably have the same bug.) > In the case where we > open the fp for write access, the FreeBSD behavior is unchanged: > > errno = 19, rc = 0 > fwrite errno = 0, rc = 18 > > Which gives us ENODEV for the fputs(3) and no error for the fwrite(3). > I'm not sure why an error is returned at all in the fputs(3) case since > it seems perfectly valid to write onto /dev/null and simply have the > data be discarded, but that error is coming back from somewhere deeper > of the bowels of stdio and has nothing to do with my proposed diff in > any case. Red Hat Linux, interestingly enough, returns errno 25 in > this case (ENOTTY)! I'll bet the isatty() call in __smakebuf() is setting errno because /dev/null doesn't support the relevant ioctl. Note that rc=0 so libc is ignoring the error and completing the write, even though it spuriously sets errno. In any case, you're right that this is an unrelated bug. > This is your libc. This is your libc on SUSv2*. Any questions? ASCII stupid question, get a stupid ANSI. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
