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

From: Eivind Eklund (eivind_at_FreeBSD.org)
Date: 03/02/04

  • Next message: Andrey Chernov: "Re: Another conformance question... This time fputs()." 
    Date: Tue, 2 Mar 2004 10:35:43 +0000
To: "Jordan K. Hubbard" <jkh@queasyweasel.com>

    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
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Andrey Chernov: "Re: Another conformance question... This time fputs()."

    Relevant Pages

    • Re: [perfmon] Re: [perfmon2] perfmon2 merge news
      ... This is basically a read(or for other syscalls a write) on something ... else than the file descriptor provided to the system call. ... The request in this case is "tell me about this particular collection ... of PMDs" and the reply is the values. ...
      (Linux-Kernel)
    • Need another pair of eyes to figure this one out
      ... some class libraries and in doing so am using some driver programs to ... I'm opening a file descriptor and also opening a file that ... // lot's more headers because the fd I'm writing to a socket ...
      (alt.comp.lang.learn.c-cpp)
    • Re: Apache 2.x leaked descriptors
      ... > the cgi has access to the error log via its stderr file descriptor 2. ... Simply writing any data to the open fd might confuse ...
      (Vuln-Dev)
    • Re: select()/write() semantics
      ... A file descriptor is considered ready if it is ... writing all n bytes; ... then if select reports that a file descriptor ... int fds; ...
      (comp.os.linux.development.apps)
    • write(2) takes > 17 seconds even with O_NONBLOCK
      ... I've always thought that writing to a file descriptor with O_NONBLOCK ... I have a C program writing to stdout, which is set to O_NONBLOCK, ... and the shell redirects stdout to a regular disk file. ...
      (freebsd-questions)