Date: Tue, 2 Mar 2004 08:53:23 -0800 From: David Schultz <das@FreeBSD.ORG> To: "Jordan K. Hubbard" <jkh@queasyweasel.com> Cc: standards@FreeBSD.ORG Subject: Re: Another conformance question... This time fputs(). Message-ID: <20040302165323.GA17665@VARK.homeunix.com> In-Reply-To: <F648D56F-6C28-11D8-9000-000393BB9222@queasyweasel.com> References: <F648D56F-6C28-11D8-9000-000393BB9222@queasyweasel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040302165323.GA17665>