which functions set the end-of-file indicator?

Discussion in 'C Programming' started by nicolas.sitbon@gmail.com, Aug 4, 2008.

  1. Guest

    Hi everybody, in a french C book, the author says that only {fgetc,
    getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
    fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
    are guaranteed to set the end-of-file indicator when the end-of-file
    is reached, but in C99 standard, I find p 288 (ISO/IEC 9899:TC3
    Committee Draft — Septermber 7, 2007 WG14/N1256)

    /* ============================= */
    #include <stdio.h>
    /* ... */
    int count; float quant; char units[21], item[21];
    do {
    count = fscanf(stdin, "%f%20s of %20s", &quant, units, item);
    fscanf(stdin,"%*[^\n]");
    } while (!feof(stdin) && !ferror(stdin));
    /* ============================= */
    It seems to say that fscanf family function set end-of-file indicator
    too? which functions set the end-of-file indicator?
    , Aug 4, 2008
    #1
    1. Advertising

  2. Guest

    On Aug 4, 9:05 pm, wrote:
    <snip>

    > It seems to say that fscanf family function set end-of-file indicator
    > too? which functions set the end-of-file indicator?


    All functions that perform IO operations. (ie even perror() can set
    the 'error' indicator for stderr if an error occurs at writing)
    , Aug 4, 2008
    #2
    1. Advertising

  3. Chris Torek Guest

    In article <>
    <> wrote:
    >Hi everybody, in a french C book, the author says that only {fgetc,
    >getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
    >fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
    >are guaranteed to set the end-of-file indicator when the end-of-file
    >is reached ...


    This is incorrect. In the "obviously wrong" part, putc() is not
    going to set the end-of-file indicator, for instance. :) But it
    is still wrong, and perhaps overly complicated.

    All I/O is done "as if" via fgetc() and fputc(). If fgetc() would
    have set the end-of-file indicator, any other input-oriented
    operation that would have called fgetc() must also set the e-o-f
    indicator. (And of course, if fgetc() would have set the error
    indicator, any other input-oriented operation that would have called
    fgetc() must also set the error indicator. The "would have"s here
    simply mean that, deep inside the implementation, scanf() or fread()
    or whatever might use something "faster" or "better" than an actual
    call to fgetc(), such as an inline expansion of what fgetc() does.
    But if they do avoid fgetc() in favor of something "better", they
    still have to act *as if* they had made an actual call to fgetc(),
    including setting the e-of-f and/or error indicators in the same
    way that fgetc() would have.)

    (For instance, an implementation might have a macro like this:

    #define fast_inlined_getc(f) \
    ((f)->_readcount > 0 ? --(f)->_readcount, *(f)->_readptr++ : \
    fgetc(f))

    and it could then use this in the scanf engine. The fgets() and
    fread() functions might look directly at f->_readcount:

    int fgets(char *buf, size_t bufsize, FILE *stream) {
    ...
    p = memchr(f->_readptr, '\n', min(f->_readsize, room_in_user_buffer));
    if (p != NULL) {
    /*
    * Found entire input line in current buffer. Do a quick
    * copy-and-take.
    */
    line_len = p - f->_readptr; /* length of the line */
    memcpy(buf, f->_readptr, line_len); /* copy it */
    f->_readptr += line_len; /* and take it out */
    f->_readsize -= line_len; /* of the stdio buffer */
    } else {
    /*
    * Found only part of line in current buffer, or buffer
    * is empty. Do whatever is required to copy partial
    * line (if any) and read more input, in a loop as needed.
    */
    ...
    }
    ...
    }

    At some point, though, these all call fgetc() (or the underlying
    code that implements fgetc()) to refill the stdio buffer. It is
    this code that handles "read from underlying file or device"
    requests, and it is this "read from underlying file or device"
    request that encounters the kinds of failures that set the end-of-file
    and/or error indicators.)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: gmail (figure it out) http://web.torek.net/torek/index.html
    Chris Torek, Aug 4, 2008
    #3
  4. Guest

    OK OK, everybody seems to be ok to say that all I/O functions can
    potentially set/clear the end-of-file indicator, but nobody give me
    normative reference, and the author says that nothing in the C99 says
    that all I/O functions can set/clear end-of-file indicator!!!
    , Aug 4, 2008
    #4
  5. santosh Guest

    wrote:

    > OK OK, everybody seems to be ok to say that all I/O functions can
    > potentially set/clear the end-of-file indicator, but nobody give me
    > normative reference, and the author says that nothing in the C99 says
    > that all I/O functions can set/clear end-of-file indicator!!!


    Here you go:

    <http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=29237>
    santosh, Aug 4, 2008
    #5
  6. santosh Guest

    Eric Sosman wrote:

    > wrote:
    >> OK OK, everybody seems to be ok to say that all I/O functions can
    >> potentially set/clear the end-of-file indicator, but nobody give me
    >> normative reference, and the author says that nothing in the C99 says
    >> that all I/O functions can set/clear end-of-file indicator!!!

    >
    > Unless the post hasn't reached my news server yet, nobody has
    > claimed that all I/O functions can set or clear the end-of-file
    > indicator. putc(), for example, cannot. Nor can ftell(), nor
    > setvbuf(), nor feof(), nor a bunch of others.


    To quote vippstar:

    All functions that perform IO operations. (ie even perror() can set
    the 'error' indicator for stderr if an error occurs at writing)

    A bit of an overstatement, but this happens in ordinary speech. We can't
    all expect be like Keith!

    <snip>
    santosh, Aug 4, 2008
    #6
  7. Guest

    On 4 août, 21:30, Eric Sosman <> wrote:
    > wrote:
    > > OK OK, everybody seems to be ok to say that all I/O functions can
    > > potentially set/clear the end-of-file indicator, but nobody give me
    > > normative reference, and the author says that nothing in the C99 says
    > > that all I/O functions can set/clear end-of-file indicator!!!

    >
    >
    >      The normative reference is section 7.19 of the Standard.
    >
    > --
    >

    I looked at this section, but I didn't find anything saying clearly
    that all IO input functions set/clear the end-of-file indicator!
    , Aug 4, 2008
    #7
  8. santosh Guest

    wrote:

    > On 4 août, 21:30, Eric Sosman <> wrote:
    >> wrote:
    >> > OK OK, everybody seems to be ok to say that all I/O functions can
    >> > potentially set/clear the end-of-file indicator, but nobody give me
    >> > normative reference, and the author says that nothing in the C99
    >> > says that all I/O functions can set/clear end-of-file indicator!!!

    >>
    >>
    >> The normative reference is section 7.19 of the Standard.


    > I looked at this section, but I didn't find anything saying clearly
    > that all IO input functions set/clear the end-of-file indicator!


    Hasn't it been made clear to you by now that only one poster has said
    that all functions that perform an I/O operation set these flags, and
    that he was overstating his case, as has been explained more than once?
    santosh, Aug 4, 2008
    #8
  9. Guest

    On 4 août, 21:59, santosh <> wrote:
    > wrote:
    > > On 4 août, 21:30, Eric Sosman <> wrote:
    > >> wrote:
    > >> > OK OK, everybody seems to be ok to say that all I/O functions can
    > >> > potentially set/clear the end-of-file indicator, but nobody give me
    > >> > normative reference, and the author says that nothing in the C99
    > >> > says that all I/O functions can set/clear end-of-file indicator!!!

    >
    > >> The normative reference is section 7.19 of the Standard.

    > > I looked at this section, but I didn't find anything saying clearly
    > > that all IO INPUT functions set/clear the end-of-file indicator!

    >
    > Hasn't it been made clear to you by now that only one poster has said
    > that all functions that perform an I/O operation set these flags, and
    > that he was overstating his case, as has been explained more than once?


    read what I said : all IO INPUT functions
    , Aug 4, 2008
    #9
  10. santosh Guest

    wrote:

    > On 4 août, 21:59, santosh <> wrote:
    >> wrote:
    >> > On 4 août, 21:30, Eric Sosman <> wrote:
    >> >> wrote:
    >> >> > OK OK, everybody seems to be ok to say that all I/O functions
    >> >> > can potentially set/clear the end-of-file indicator, but nobody
    >> >> > give me normative reference, and the author says that nothing in
    >> >> > the C99 says that all I/O functions can set/clear end-of-file
    >> >> > indicator!!!

    >>
    >> >> The normative reference is section 7.19 of the Standard.
    >> > I looked at this section, but I didn't find anything saying clearly
    >> > that all IO INPUT functions set/clear the end-of-file indicator!

    >>
    >> Hasn't it been made clear to you by now that only one poster has said
    >> that all functions that perform an I/O operation set these flags, and
    >> that he was overstating his case, as has been explained more than
    >> once?

    >
    > read what I said : all IO INPUT functions


    You have already been told that all input in C is done as if it is
    composed of one or more calls to fgetc, and fgetc can most certainly
    set the end-of-file indicator, and it's implied that other input
    functions modelled on top of it, must also do so. Indeed they have no
    choice but to do so. However they do have different methods of
    notifying the user of such an exception. For example fgets returns a
    null pointer, fread returns a short item count, scanf returns EOF etc.
    In all cases you can always determine whether a particular FILE stream
    is at end-of-file by calling the feof function, and whether an I/O
    error has occurred during the last access by using the ferror function.
    santosh, Aug 4, 2008
    #10
  11. Guest

    wrote:
    > On 4 ao�t, 21:30, Eric Sosman <> wrote:

    ...
    > > � � �The normative reference is section 7.19 of the Standard.
    > >
    > > --
    > >

    > I looked at this section, but I didn't find anything saying clearly
    > that all IO input functions set/clear the end-of-file indicator!


    It doesn't explain it in those terms. You have to follow several
    intermediate steps.

    7.19.7.1p3 says that fgetc() sets the end-of-file indicator.
    7.24.3.1p3 says the same for fgetwc(). All wide character input
    functions have their behavior defined in terms of successive calls to
    fgetwc(), and all byte input functions have their behavior defined in
    terms of repeated calls to fgetc() (7.19.3p11). All of the input
    functions are defined as either wide character input functions or byte
    input functions (7.19.1p3) . Those functions don't have to actually
    call fgetc()/fgetwc(), but must produce the same behavior as if they
    called fgetc()/fgetwc(), which means that they must set the end-of-
    file indicator, when appropriate.
    , Aug 4, 2008
    #11
  12. Guest

    On 4 août, 22:14, santosh <> wrote:
    > wrote:
    > > On 4 août, 21:59, santosh <> wrote:
    > >> wrote:
    > >> > On 4 août, 21:30, Eric Sosman <> wrote:
    > >> >> wrote:
    > >> >> > OK OK, everybody seems to be ok to say that all I/O functions
    > >> >> > can potentially set/clear the end-of-file indicator, but nobody
    > >> >> > give me normative reference, and the author says that nothing in
    > >> >> > the C99 says that all I/O functions can set/clear end-of-file
    > >> >> > indicator!!!

    >
    > >> >> The normative reference is section 7.19 of the Standard.
    > >> > I looked at this section, but I didn't find anything saying clearly
    > >> > that all IO INPUT functions set/clear the end-of-file indicator!

    >
    > >> Hasn't it been made clear to you by now that only one poster has said
    > >> that all functions that perform an I/O operation set these flags, and
    > >> that he was overstating his case, as has been explained more than
    > >> once?

    >
    > > read what I said : all IO INPUT functions

    >
    > You have already been told that all input in C is done as if it is
    > composed of one or more calls to fgetc, and fgetc can most certainly
    > set the end-of-file indicator, and it's implied that other input
    > functions modelled on top of it, must also do so. Indeed they have no
    > choice but to do so. However they do have different methods of
    > notifying the user of such an exception. For example fgets returns a
    > null pointer, fread returns a short item count, scanf returns EOF etc.
    > In all cases you can always determine whether a particular FILE stream
    > is at end-of-file by calling the feof function, and whether an I/O
    > error has occurred during the last access by using the ferror function.


    sorry but, one more time, you don't answer me : can you say precisely,
    where in the normative reference it is write that all IO INPUT
    functions clear/set the end-of-file indicator cause if I write to the
    author without any proof...
    , Aug 4, 2008
    #12
  13. santosh Guest

    Eric Sosman wrote:

    > santosh wrote:
    >> Eric Sosman wrote:
    >>
    >>> wrote:
    >>>> OK OK, everybody seems to be ok to say that all I/O functions can
    >>>> potentially set/clear the end-of-file indicator, but nobody give me
    >>>> normative reference, and the author says that nothing in the C99
    >>>> says that all I/O functions can set/clear end-of-file indicator!!!
    >>> Unless the post hasn't reached my news server yet, nobody has
    >>> claimed that all I/O functions can set or clear the end-of-file
    >>> indicator. putc(), for example, cannot. Nor can ftell(), nor
    >>> setvbuf(), nor feof(), nor a bunch of others.

    >>
    >> To quote vippstar:
    >>
    >> All functions that perform IO operations. (ie even perror() can set
    >> the 'error' indicator for stderr if an error occurs at writing)

    >
    > The O.P. asked about the end-of-file indicator. The end-of-file
    > indicator and the error indicator are separate indicators, and are
    > set and cleared under different circumstances.


    You're right. Apologies to vippstar for misquoting him.
    santosh, Aug 4, 2008
    #13
  14. Guest

    On 4 août, 22:28, Eric Sosman <> wrote:
    >      Is it possible that you have confused the end-of-file
    > indicator with the error indicator?  They are not the same.
    >
    > --
    >


    In fact, the author says that except the functions I mentioned above,
    all other are not guaranteed to set the end-of-file OR error
    indicator, and he says that other functions are not portable if used
    in this way. For french programmers who want to verify my saying, the
    book is "méthodologie de la programmation en C, norme C99, API POSIX"
    de Achille Braquelaire.
    , Aug 4, 2008
    #14
  15. Guest

    Eric Sosman wrote:
    ....
    > statement about all input functions. (Indeed, the Standard never
    > defines "input functions" as such, although it does define some
    > close relatives.)
    >
    > If we take the commonsense view that "input functions" are the
    > "wide character input functions" (7.19.1p5) ...


    Which starts out saying "The input/output functions are given the
    following collective terms"

    > ... plus fgetc, fgets, fread,
    > fscanf, getc, getchar, gets, scanf, vfscanf, and vscanf,


    All of which fall into the category defined by 7.19.1p5 as "byte input/
    output functions".

    The standard may fail to distinguish between byte input and byte
    output functions, but is anyone seriously in doubt as to which of the
    byte input/output functions are input functions, and which ones are
    output functions?

    > ... I believe
    > that the description of each says it can set the end-of-file
    > indicator. (I haven't checked, but you're welcome to -- and


    I have. The ones that process more than one character at a time don't
    say so directly. You have to invoke 7.19.3p11 to determine that they
    are also required to set it.
    , Aug 4, 2008
    #15
  16. Guest

    On 4 août, 22:48, Eric Sosman <> wrote:
    > Eric Sosman wrote:
    > > wrote:
    > >> On 4 août, 21:30, Eric Sosman <> wrote:
    > >>> wrote:
    > >>>> OK OK, everybody seems to be ok to say that all I/O functions can
    > >>>> potentially set/clear the end-of-file indicator, but nobody give me
    > >>>> normative reference, and the author says that nothing in the C99 says
    > >>>> that all I/O functions can set/clear end-of-file indicator!!!

    >
    > >>>      The normative reference is section 7.19 of the Standard.

    >
    > >> I looked at this section, but I didn't find anything saying clearly
    > >> that all IO input functions set/clear the end-of-file indicator!

    >
    > >     It's in the same paragraph that says the Moon is made of
    > > green cheese.  In other words, the Standard says no such thing:
    > > You are searching for the normative text of a falsehood.

    >
    > >     Is it possible that you have confused the end-of-file
    > > indicator with the error indicator?  They are not the same.

    >
    >      Pardon me; I overlooked the insertion of the word "input" in
    > your restatement of the question.  Yes, the Standard says that all
    > input functions can set the end-of-file indicator, but it says so
    > in the descriptions of the individual functions, not as a blanket
    > statement about all input functions.  (Indeed, the Standard never
    > defines "input functions" as such, although it does define some
    > close relatives.)
    >
    >      If we take the commonsense view that "input functions" are the
    > "wide character input functions" (7.19.1p5) plus fgetc, fgets, fread,
    > fscanf, getc, getchar, gets, scanf, vfscanf, and vscanf, I believe
    > that the description of each says it can set the end-of-file
    > indicator.  (I haven't checked, but you're welcome to -- and
    > maybe to file a Defect Report if any of them forgets to!)  You can
    > also search the function descriptions for those that clear or can
    > clear the end-of-file indicator; it would be somewhat clumsier to
    > make a blanket statement about the latter category.
    >
    > --
    >


    I checked and for example, the fscanf function, nothing says that it
    sets the end-of-file indicator except perhaps this example :

    #include <stdio.h>
    /* ... */
    int count; float quant; char units[21], item[21];
    do {
    count = fscanf(stdin, "%f%20s of %20s", &quant, units, item);
    fscanf(stdin,"%*[^\n]");
    } while (!feof(stdin) && !ferror(stdin));
    , Aug 4, 2008
    #16
  17. On Mon, 4 Aug 2008 12:50:23 -0700 (PDT),
    wrote:

    >On 4 août, 21:30, Eric Sosman <> wrote:
    >> wrote:
    >> > OK OK, everybody seems to be ok to say that all I/O functions can
    >> > potentially set/clear the end-of-file indicator, but nobody give me
    >> > normative reference, and the author says that nothing in the C99 says
    >> > that all I/O functions can set/clear end-of-file indicator!!!

    >>
    >>
    >>      The normative reference is section 7.19 of the Standard.
    >>
    >> --
    >>

    >I looked at this section, but I didn't find anything saying clearly
    >that all IO input functions set/clear the end-of-file indicator!


    Since it is obviously false, you shouldn't. Read 7.19.3-11 followed
    by 7.19.7.1-3 to learn when it is set. You should then be able to
    find on your own when it is cleared.

    --
    Remove del for email
    Barry Schwarz, Aug 4, 2008
    #17
  18. Guest

    On 4 août, 22:58, wrote:
    > Eric Sosman wrote:
    > I have. The ones that process more than one character at a time don't
    > say so directly. You have to invoke 7.19.3p11 to determine that they
    > are also required to set it.


    11 The wide character input functions read multibyte characters from
    the stream and convert
    them to wide characters as if they were read by successive calls to
    the fgetwc function.
    Each conversion occurs as if by a call to the mbrtowc function,
    with the conversion state
    described by the stream’s own mbstate_t object. The byte input
    functions read
    characters from the stream as if by successive calls to the fgetc
    function.


    Many thanks to everybody, this time it's clear for me.
    , Aug 4, 2008
    #18
  19. On Mon, 04 Aug 2008 14:06:55 -0700, nicolas.sitbon wrote:
    > I checked and for example, the fscanf function, nothing says that it
    > sets the end-of-file indicator


    Okay, maybe an example is clearer for you.

    7.19.1p5 (Input/output <stdio.h>; Introduction)
    "The byte input/output functions [...]: [...], fscanf, [...]"

    7.19.3p11 (Files)
    "The byte input functions read characters from the stream as if by
    successive calls to the fgetc function."

    7.19.7.1p3 (The fgetc function)
    "If [...] the stream is at end-of-file, the end-of-file indicator for the
    stream is set [...]"

    Yes, it doesn't explicitly say that fscanf sets the end-of-file indicator.
    But a conforming implementation where fscanf *doesn't* set the end-of-file
    indicator cannot exist; it would have to break one of these three
    requirements. Either it doesn't classify fscanf as a byte input function,
    or it doesn't make byte input functions read input as if by successive
    calls to fgetc, or it doesn't make fgetc set the end-of-file indicator.
    Harald van Dijk, Aug 4, 2008
    #19
  20. Flash Gordon Guest

    Malcolm McLean wrote, On 04/08/08 19:27:
    >
    > <> wrote in message news:
    >> Hi everybody, in a french C book, the author says that only {fgetc,
    >> getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
    >> fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
    >> are guaranteed to set the end-of-file indicator when the end-of-file
    >> is reached.

    >
    > The book is wrong, at least to all intents and purposes. EOF will be
    > returned after the contents of the file have been exhausted by any of
    > the read functions. feof() returns true after the first read to return EOF.


    The above is at least misleading. EOF is a macro which evaluates to an
    integer constant. Since some of the input functions return pointers you
    are obviously wrong about all of the input functions being able to
    return its value. Also for those which can return EOF they can do so
    because of an error, and if it is an error causing the routine to return
    EOF then feof() will not return true but ferror() will.

    > I think what he is thinking is that if a call to a function like
    > fscanf() doesn't match the input format than you'll get a partial read -
    > the function will return the number of arguments successfully converted
    > - and EOF may not be set, even if you are very close to the end of the
    > file and have no complete records left.


    Well, that appears to not be what the OP's book was referring to, but it
    is true.
    --
    Flash Gordon
    Flash Gordon, Aug 4, 2008
    #20
    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. Marko Vuksanovic

    File Upload Progress Indicator

    Marko Vuksanovic, Jun 22, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    558
  2. Marko Vuksanovic

    File Upload Progress Indicator ?

    Marko Vuksanovic, Jun 23, 2006, in forum: ASP .Net
    Replies:
    6
    Views:
    10,951
  3. Andrew
    Replies:
    7
    Views:
    345
    Andrew
    Oct 1, 2003
  4. Marcus Kwok

    File Read Progress Indicator

    Marcus Kwok, May 18, 2007, in forum: C++
    Replies:
    7
    Views:
    359
    Marcus Kwok
    May 22, 2007
  5. Austin Bingham
    Replies:
    1
    Views:
    299
    Austin Bingham
    Jan 30, 2010
Loading...

Share This Page