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

[Eivind Eklund]

On Tue, Mar 02, 2004 at 02:04:59AM -0800, Jordan K. Hubbard wrote:
> Given that it's just not kosher to write on a read-only fp and get no 
> error back at all, I would argue (though not passionately) for the 
> following diff to libc:
> 
> --- stdio/fvwrite.c     22 Mar 2002 21:53:04 -0000      1.15
> +++ stdio/fvwrite.c     2 Mar 2004 08:40:25 -0000
> @@ -43,6 +43,7 @@
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>
> +#include <errno.h>
>  #include "local.h"
>  #include "fvwrite.h"
> 
> @@ -67,8 +68,10 @@
>         if ((len = uio->uio_resid) == 0)
>                 return (0);
>         /* make sure we can write */
> -       if (cantwrite(fp))
> +       if (cantwrite(fp)) {
> +               errno = EACCES;
>                 return (EOF);
> +       }
> 
>  #define        MIN(a, b) ((a) < (b) ? (a) : (b))
>  #define        COPY(n)   (void)memcpy((void *)fp->_p, (void *)p, 
> (size_t)(n))
> 
> 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.   In the case where we 
> open the fp for write access, the FreeBSD behavior is unchanged:

Based on a quick reading of the SUSv2 putc manpage[*] (which is what
documents the errors for fwrite and fputs), I'd say the following error
seems appropriate:

[EBADF]
    The file descriptor underlying stream is not a valid file descriptor
    open for writing.

If we open the file for writing, I think we should get:

[ENXIO]
    A request was made of a non-existent device, or the request was
    outside the capabilities of the device.

EACCES is not allowed at all from these calls.

Eivind.

[*] The fputc manpage is at:
http://www.opengroup.org/onlinepubs/007908799/xsh/fputc.html