Another conformance question... This time fputs().
David Schultz
das at FreeBSD.ORG
Tue Mar 2 08:54:13 PST 2004
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.
More information about the freebsd-hackers
mailing list