Another conformance question... This time fputs().

[David Schultz]

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.