conforming implementation?

Discussion in 'C Programming' started by vippstar@gmail.com, May 18, 2008.

  1. Guest

    If the concept of file streams is not possible to be implemented, can
    all FILE related functions be "disabled"?
    For example:

    size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE
    *stream) {
    errno = something;
    return 0;
    }

    Perhaps to generalize the question: When the behavior (or return
    value) of a function is unspecified by the standard, can an
    implementation always choose one behavior?

    All replies appreciated.
     
    , May 18, 2008
    #1
    1. Advertising

  2. Jack Klein <> writes:
    [...]
    > There are two types of possible conforming implementations, hosted and
    > free standing. A hosted environment must begin execution of a
    > program with three FILE streams already open, which can be referred to
    > by the macros stdin, stdout, and stderr. All the appropriate FILE
    > functions must be available on these streams.


    Yes, but those functions aren't necessarily required to succeed. For
    example (using Unix shell syntax), given:

    ./my_program < /dev/null \
    > /this_disk_is_full/out \

    2> /this_disk_is_full/err

    any attempt to read from stdin or write to stdout or stderr will fail.
    I'm not convinced that a hosted implementation in which stdin, stdout,
    and stderr are *always* unusable would be non-conforming.

    The standard is written to allow for conforming implementations on a
    wide variety of systems. One consequence of this is that it doesn't
    require a conforming implementation to be *useful* (how could it?).

    > A free standing environment, on the other hand, is not even required
    > to provide <stdio.h> or file streams at all.


    Right.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 19, 2008
    #2
    1. Advertising

  3. Keith Thompson wrote:
    > Jack Klein <> writes:
    > [...]
    > > There are two types of possible conforming implementations,
    > > hosted and free standing. A hosted environment must begin
    > > execution of a program with three FILE streams already open,
    > > which can be referred to by the macros stdin, stdout, and
    > > stderr. All the appropriate FILE functions must be
    > > available on these streams.

    >
    > Yes, but those functions aren't necessarily required to
    > succeed. For example (using Unix shell syntax), given:
    >
    > ./my_program < /dev/null \
    > > /this_disk_is_full/out \

    > 2> /this_disk_is_full/err
    >
    > any attempt to read from stdin or write to stdout or stderr
    > will fail. I'm not convinced that a hosted implementation in
    > which stdin, stdout, and stderr are *always* unusable would
    > be non-conforming.


    I would argue that the user who typed the command has
    chosen to run the program on a non-conforming implementation.

    --
    Peter
     
    Peter Nilsson, May 19, 2008
    #3
  4. Guest

    On May 18, 4:21 am, wrote:
    > If the concept of file streams is not possible to be implemented, can
    > all FILE related functions be "disabled"?



    I suspect it would be confirming, although not all that useful, if a
    hosted implementation failed all fopens, immediately returned EOF for
    stdin, and bit-bucketed any writes to stdout and strerr.
     
    , May 19, 2008
    #4
  5. Peter Nilsson <> writes:
    > Keith Thompson wrote:
    >> Jack Klein <> writes:
    >> [...]
    >> > There are two types of possible conforming implementations,
    >> > hosted and free standing. A hosted environment must begin
    >> > execution of a program with three FILE streams already open,
    >> > which can be referred to by the macros stdin, stdout, and
    >> > stderr. All the appropriate FILE functions must be
    >> > available on these streams.

    >>
    >> Yes, but those functions aren't necessarily required to
    >> succeed. For example (using Unix shell syntax), given:
    >>
    >> ./my_program < /dev/null \
    >> > /this_disk_is_full/out \

    >> 2> /this_disk_is_full/err
    >>
    >> any attempt to read from stdin or write to stdout or stderr
    >> will fail. I'm not convinced that a hosted implementation in
    >> which stdin, stdout, and stderr are *always* unusable would
    >> be non-conforming.

    >
    > I would argue that the user who typed the command has
    > chosen to run the program on a non-conforming implementation.


    An interesting thought, but I disagree. After all, the various I/O
    functions are designed to detect errors for a reason.

    If I write to stdout and the disk fills up after I've written a
    gigabyte of data, and the implementation correctly tells me about the
    error, that's not non-conforming. Same thing if it fills up after I
    write a megabyte of data. Or a kilobyte. Or none.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 19, 2008
    #5
  6. Pietro Cerutti <> writes:
    > Keith Thompson wrote:
    >> Jack Klein <> writes:
    >> [...]
    >>> There are two types of possible conforming implementations, hosted and
    >>> free standing. A hosted environment must begin execution of a
    >>> program with three FILE streams already open, which can be referred to
    >>> by the macros stdin, stdout, and stderr. All the appropriate FILE
    >>> functions must be available on these streams.

    >> Yes, but those functions aren't necessarily required to succeed. For
    >> example (using Unix shell syntax), given:
    >> ./my_program < /dev/null \
    >> > /this_disk_is_full/out \

    >> 2> /this_disk_is_full/err
    >> any attempt to read from stdin or write to stdout or stderr will
    >> fail.
    >> I'm not convinced that a hosted implementation in which stdin, stdout,
    >> and stderr are *always* unusable would be non-conforming.

    >
    > I don't agree. A read from /dev/null doesn't /*fail*/, but rather
    > returns EOF:

    [snip]

    Good point.

    It's difficult to construct a good example of what I'm trying to do,
    since if the file is unreadable the error will generally be caught by
    the shell before the program is invoked. (Again, I'm using a
    Unix-specific example to illustrate a more general point.)

    Replace /dev/null with some file or device that can be opened for
    reading but on which any read attempts will actually fail and set the
    error flag for the stream. I'm still not convinced that this would be
    non-conforming. To demonstrate that it *is* non-conforming, you'd
    have to find wording in the standard that says it must be possible to
    read from stdin without error. It may be ambiguous, but I don't think
    there's a clear statement to that effect.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 19, 2008
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alex Rootham
    Replies:
    2
    Views:
    597
    Richard Tobin
    Aug 28, 2003
  2. Peter Rooney

    tool to fix non-conforming xml?

    Peter Rooney, Feb 5, 2006, in forum: XML
    Replies:
    2
    Views:
    573
    Henry S. Thompson
    Feb 6, 2006
  3. ik
    Replies:
    6
    Views:
    803
    Rich Grise
    Sep 11, 2004
  4. Scorpio

    C99 conforming compilers

    Scorpio, Jan 31, 2006, in forum: C Programming
    Replies:
    5
    Views:
    339
    Randy Howard
    Feb 1, 2006
  5. Replies:
    12
    Views:
    586
    James Kanze
    Jul 31, 2007
Loading...

Share This Page