EOF

Discussion in 'C Programming' started by Richard Tobin, Sep 19, 2007.

  1. In article <>,
    lak <> wrote:

    >why EOF has an -1 value.what's the purpose to make it as -1. can any
    >one tell answer for this?


    It doesn't have to have the value -1. It has a negative value so that
    it can be easily distinguished from real characters when returned from
    getc() and the like.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Sep 19, 2007
    #1
    1. Advertising

  2. Richard Tobin

    lak Guest

    why EOF has an -1 value.what's the purpose to make it as -1. can any
    one tell answer for this?
    lak, Sep 19, 2007
    #2
    1. Advertising

  3. Richard Tobin

    Mark Bluemel Guest

    lak wrote:
    > why EOF has an -1 value.what's the purpose to make it as -1. can any
    > one tell answer for this?


    RTFM is an obvious answer. Hint: The logic is essentially the same as
    that which stipulates that getchar() (etc) return int not char...

    I picked up my copy of K&R (first edition, somewhat battered :) and
    found that at the time that was written there were two common EOF
    conventions, one of which could be handled by getchar() returning a char
    rather than an int... (Of course it had its own problems).
    Mark Bluemel, Sep 19, 2007
    #3
  4. Richard Tobin

    CBFalconer Guest

    lak wrote:
    >
    > why EOF has an -1 value.what's the purpose to make it as -1. can
    > any one tell answer for this?


    The only requirement for EOF is that it be negative.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Sep 19, 2007
    #4
  5. lak wrote:
    > why EOF has an -1 value.what's the purpose to make it as -1. can any
    > one tell answer for this?


    It doesn't. It could be any negative integral constant expression. The
    reason is simple: to make EOF an encoding other than those used for
    legitimate characters. That is why functions (or macros) like fgetc,
    getc, and getchar return ints instead of chars. Did you check the FAQ
    (or an elementary textbook) before posting? It's a good idea to do so;
    many people, even the sweetest on occassion, get quite steamed at
    elementary questions already answered in the FAQ.
    Martin Ambuhl, Sep 19, 2007
    #5
  6. Richard Tobin

    bluey Guest

    On 19 Sep, 12:15, lak <> wrote:
    > why EOF has an -1 value.what's the purpose to make it as -1. can any
    > one tell answer for this?


    The actual answer is quite simple. you need to learn - as do many -
    about the registers on the cpu itself. given that 0 in acsii is a
    value (albiet a Null value) the only way a processor can see past this
    is by checking the carry bit flag. by passing a -1 to the register it
    can see a processor condition of carry (or not in this case0.
    bluey, Sep 19, 2007
    #6
  7. bluey wrote:
    > On 19 Sep, 12:15, lak <> wrote:
    >> why EOF has an -1 value.what's the purpose to make it as -1. can any
    >> one tell answer for this?

    >
    > The actual answer is quite simple. you need to learn - as do many -
    > about the registers on the cpu itself. given that 0 in acsii is a
    > value (albiet a Null value) the only way a processor can see past this
    > is by checking the carry bit flag. by passing a -1 to the register it
    > can see a processor condition of carry (or not in this case0.


    Either "bluey" is making a joke, which is in very poor taste since the
    person asking the question may take him seriously, or he's an idiot. In
    either case you should ignore his blathering.
    Martin Ambuhl, Sep 20, 2007
    #7
  8. bluey <> writes:
    > On 19 Sep, 12:15, lak <> wrote:
    >> why EOF has an -1 value.what's the purpose to make it as -1. can any
    >> one tell answer for this?

    >
    > The actual answer is quite simple. you need to learn - as do many -
    > about the registers on the cpu itself. given that 0 in acsii is a
    > value (albiet a Null value) the only way a processor can see past this
    > is by checking the carry bit flag. by passing a -1 to the register it
    > can see a processor condition of carry (or not in this case0.


    Knowing about CPU registers is not necessary at all, or even
    particularly helpful in this case.

    fgetc() returns an int value which is either:
    the next character read from the input stream (interpreted as an
    unsigned char and converted to int;
    or:
    a distinct value, namely the value of the macro EOF, to indicate
    end-of-file or an error condition.

    The standard requires EOF to have a negative value. (It doesn't
    require it to be -1; I've never heard of an implementation where it's
    defined as anything other than -1, but I still wouldn't assume
    anything beyond what the standard guarantees).

    Since a valid unsigned char value can be any non-negative value in the
    range 0 to UCHAR_MAX, it makes sense to use a negative value if you
    need something distinct from all possible unsigned char values.

    Note the cpomlete lack in this explanation of any mention of CPU
    registers, condition codes, or carry bits. It's all about values, not
    representations. And since most code checks whether the result is
    equal (or unequal) to EOF, the fact that it's negative doesn't
    typically even matter. The standard *could* have allowed EOF to be
    defined as (UCHAR_MAX + 1), for example.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 20, 2007
    #8
  9. Richard Tobin

    Ben Pfaff Guest

    bluey <> writes:

    > On 19 Sep, 12:15, lak <> wrote:
    >> why EOF has an -1 value.what's the purpose to make it as -1. can any
    >> one tell answer for this?

    >
    > The actual answer is quite simple. you need to learn - as do many -
    > about the registers on the cpu itself. given that 0 in acsii is a
    > value (albiet a Null value) the only way a processor can see past this
    > is by checking the carry bit flag. by passing a -1 to the register it
    > can see a processor condition of carry (or not in this case0.


    This answer is, at best, at the wrong level of abstraction for
    the question. At worst, it is incorrect and misleading. I would
    advise the OP to disregard it.
    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
    =b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
    2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
    Ben Pfaff, Sep 20, 2007
    #9
  10. CBFalconer said:

    > lak wrote:
    >>
    >> why EOF has an -1 value.what's the purpose to make it as -1. can
    >> any one tell answer for this?

    >
    > The only requirement for EOF is that it be negative.


    No, it must also have integral type. #define EOF -3.14159 would not be
    conforming.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Sep 20, 2007
    #10
  11. Richard Heathfield <> writes:
    > CBFalconer said:
    >> lak wrote:
    >>> why EOF has an -1 value.what's the purpose to make it as -1. can
    >>> any one tell answer for this?

    >>
    >> The only requirement for EOF is that it be negative.

    >
    > No, it must also have integral type. #define EOF -3.14159 would not be
    > conforming.


    Specifically, it must expand to an integer constant expression with
    type int and a negative value.

    #define EOF (-1L)

    would not be conforming. Nor would

    #define EOF -1

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 20, 2007
    #11
  12. "Keith Thompson" <> a écrit dans le message de news:
    ...
    > bluey <> writes:
    >> On 19 Sep, 12:15, lak <> wrote:
    >>> why EOF has an -1 value.what's the purpose to make it as -1. can any
    >>> one tell answer for this?

    >>
    >> The actual answer is quite simple. you need to learn - as do many -
    >> about the registers on the cpu itself. given that 0 in acsii is a
    >> value (albiet a Null value) the only way a processor can see past this
    >> is by checking the carry bit flag. by passing a -1 to the register it
    >> can see a processor condition of carry (or not in this case0.

    >
    > Knowing about CPU registers is not necessary at all, or even
    > particularly helpful in this case.
    >
    > fgetc() returns an int value which is either:
    > the next character read from the input stream (interpreted as an
    > unsigned char and converted to int;
    > or:
    > a distinct value, namely the value of the macro EOF, to indicate
    > end-of-file or an error condition.
    >
    > The standard requires EOF to have a negative value. (It doesn't
    > require it to be -1; I've never heard of an implementation where it's
    > defined as anything other than -1, but I still wouldn't assume
    > anything beyond what the standard guarantees).
    >
    > Since a valid unsigned char value can be any non-negative value in the
    > range 0 to UCHAR_MAX, it makes sense to use a negative value if you
    > need something distinct from all possible unsigned char values.
    >
    > Note the cpomlete lack in this explanation of any mention of CPU
    > registers, condition codes, or carry bits. It's all about values, not
    > representations. And since most code checks whether the result is
    > equal (or unequal) to EOF, the fact that it's negative doesn't
    > typically even matter. The standard *could* have allowed EOF to be
    > defined as (UCHAR_MAX + 1), for example.


    That would have required that UCHAR_MAX < INT_MAX.

    Interestingly, on architectures where UCHAR_MAX > INT_MAX, converting an
    unsigned char to an int with a simple cast invokes undefined behaviour. On
    architectures with non 2's complement, int can have fewer distinguishible
    values than unsigned char. Even on 2's complement, EOF could be
    undistinguishable from a valid char read from the stream.

    The classic idiom:

    int c;
    while ((c = getc(fp)) != EOF) {
    ...
    }

    would need to be changed to:

    int c;
    while ((c = getc(fp)) != EOF || !feof(fp)) {
    ...
    }

    And still could not account for the exact contents of the stream.

    How ugly!

    --
    Chqrlie
    Charlie Gordon, Sep 20, 2007
    #12
  13. Richard Tobin

    Coos Haak Guest

    Op Thu, 20 Sep 2007 09:33:55 +0200 schreef Charlie Gordon:

    <snip>
    > That would have required that UCHAR_MAX < INT_MAX.
    >
    > Interestingly, on architectures where UCHAR_MAX > INT_MAX, converting an
    > unsigned char to an int with a simple cast invokes undefined behaviour. On
    > architectures with non 2's complement, int can have fewer distinguishible
    > values than unsigned char. Even on 2's complement, EOF could be
    > undistinguishable from a valid char read from the stream.
    >
    > The classic idiom:
    >
    > int c;
    > while ((c = getc(fp)) != EOF) {
    > ...
    > }
    >
    > would need to be changed to:
    >
    > int c;
    > while ((c = getc(fp)) != EOF || !feof(fp)) {
    > ...
    > }


    while ((c = getc(fp)) != EOF && !feof(fp)) {

    As long c isn't EOF _and_ the end of the file is not yet reached ;-)

    > And still could not account for the exact contents of the stream.
    >
    > How ugly!

    Yes!
    --
    Coos
    Coos Haak, Sep 20, 2007
    #13
  14. Richard Tobin

    CBFalconer Guest

    Charlie Gordon wrote:
    >

    .... snip ...
    >
    > int c;
    > while ((c = getc(fp)) != EOF || !feof(fp)) {
    > ...
    > }
    >
    > And still could not account for the exact contents of the stream.


    How not? Your construct seems to me to work everywhere, since the
    feof() is not called unless EOF == c, and thus does not slow up
    operation. feof() is also called only after the possible getc that
    reached EOF.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>


    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Sep 20, 2007
    #14
  15. "Coos Haak" <> a écrit dans le message de news:
    i9vuqfospqfs$...
    > Op Thu, 20 Sep 2007 09:33:55 +0200 schreef Charlie Gordon:
    >
    > <snip>
    >> That would have required that UCHAR_MAX < INT_MAX.
    >>
    >> Interestingly, on architectures where UCHAR_MAX > INT_MAX, converting an
    >> unsigned char to an int with a simple cast invokes undefined behaviour.
    >> On
    >> architectures with non 2's complement, int can have fewer distinguishible
    >> values than unsigned char. Even on 2's complement, EOF could be
    >> undistinguishable from a valid char read from the stream.
    >>
    >> The classic idiom:
    >>
    >> int c;
    >> while ((c = getc(fp)) != EOF) {
    >> ...
    >> }
    >>
    >> would need to be changed to:
    >>
    >> int c;
    >> while ((c = getc(fp)) != EOF || !feof(fp)) {
    >> ...
    >> }

    >
    > while ((c = getc(fp)) != EOF && !feof(fp)) {
    >
    > As long c isn't EOF _and_ the end of the file is not yet reached ;-)


    No, this loop will stop if getc(fp) returns EOF, which is possible before
    the end of stream if sizeof(char) == sizeof(int).

    But my loop is indeed incorrect as it does not stop in case of a read error.

    The loop could actually be written this way:

    while (c = getc(fp), !feof(fp) && !ferror(fp)) {
    ...
    }

    But that makes it even uglier.

    --
    Chqrlie.
    Charlie Gordon, Sep 20, 2007
    #15
  16. Richard Tobin

    Tor Rustad Guest

    Keith Thompson wrote:

    [...]

    > Note the cpomlete lack in this explanation of any mention of CPU
    > registers, condition codes, or carry bits. It's all about values, not
    > representations. And since most code checks whether the result is
    > equal (or unequal) to EOF, the fact that it's negative doesn't
    > typically even matter. The standard *could* have allowed EOF to be
    > defined as (UCHAR_MAX + 1), for example.


    It is interesting to note, while EOF need to be negative, the value of
    WEOF need not to, and could be e.g. (WCHAR_MAX + 1).

    --
    Tor <torust [at] online [dot] no>
    Tor Rustad, Sep 20, 2007
    #16
  17. Richard Tobin

    Coos Haak Guest

    Op Thu, 20 Sep 2007 18:36:55 +0200 schreef Charlie Gordon:

    > "Coos Haak" <> a écrit dans le message de news:
    > i9vuqfospqfs$...
    >> Op Thu, 20 Sep 2007 09:33:55 +0200 schreef Charlie Gordon:
    >>
    >> <snip>
    >>> That would have required that UCHAR_MAX < INT_MAX.
    >>>
    >>> Interestingly, on architectures where UCHAR_MAX > INT_MAX, converting an
    >>> unsigned char to an int with a simple cast invokes undefined behaviour.
    >>> On
    >>> architectures with non 2's complement, int can have fewer distinguishible
    >>> values than unsigned char. Even on 2's complement, EOF could be
    >>> undistinguishable from a valid char read from the stream.
    >>>
    >>> The classic idiom:
    >>>
    >>> int c;
    >>> while ((c = getc(fp)) != EOF) {
    >>> ...
    >>> }
    >>>
    >>> would need to be changed to:
    >>>
    >>> int c;
    >>> while ((c = getc(fp)) != EOF || !feof(fp)) {
    >>> ...
    >>> }

    >>
    >> while ((c = getc(fp)) != EOF && !feof(fp)) {
    >>
    >> As long c isn't EOF _and_ the end of the file is not yet reached ;-)

    >
    > No, this loop will stop if getc(fp) returns EOF, which is possible before
    > the end of stream if sizeof(char) == sizeof(int).
    >
    > But my loop is indeed incorrect as it does not stop in case of a read error.
    >
    > The loop could actually be written this way:
    >
    > while (c = getc(fp), !feof(fp) && !ferror(fp)) {
    > ...
    > }
    >
    > But that makes it even uglier.


    So the shortcut evaluation of C is somewhat different from mathematical
    logic. || is indeed somewhat prettier to the eye than &&. Thanks for
    remembering me.
    --
    Coos
    Coos Haak, Sep 20, 2007
    #17
  18. On 2007-09-20 13:51, CBFalconer <> wrote:
    > Charlie Gordon wrote:
    >> int c;
    >> while ((c = getc(fp)) != EOF || !feof(fp)) {
    >> ...
    >> }
    >>
    >> And still could not account for the exact contents of the stream.

    >
    > How not? Your construct seems to me to work everywhere,


    Assume that int is 16 bits with a sign-magnitude representation and
    unsigned char is also 16 bits. Then there are only 65535 different int
    values, but 65536 different unsigned char values. So two different
    unsigned char values will be mapped to the same int value (probably 0
    and 32768 will both be mapped to 0) and cannot be distinguished any
    more (immediately assigning c to an unsigned char variable may help,
    though).

    One could argue that such an implementation is not conforming, however.

    hp


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
    Peter J. Holzer, Sep 21, 2007
    #18
  19. On 2007-09-20 17:40, Coos Haak <> wrote:
    > Op Thu, 20 Sep 2007 18:36:55 +0200 schreef Charlie Gordon:
    >> "Coos Haak" <> a écrit dans le message de news:
    >> i9vuqfospqfs$...
    >>> Op Thu, 20 Sep 2007 09:33:55 +0200 schreef Charlie Gordon:
    >>>> int c;
    >>>> while ((c = getc(fp)) != EOF || !feof(fp)) {
    >>>> ...
    >>>> }
    >>>
    >>> while ((c = getc(fp)) != EOF && !feof(fp)) {
    >>>
    >>> As long c isn't EOF _and_ the end of the file is not yet reached ;-)

    >>
    >> No, this loop will stop if getc(fp) returns EOF, which is possible before
    >> the end of stream if sizeof(char) == sizeof(int).
    >>
    >> But my loop is indeed incorrect as it does not stop in case of a read error.
    >>
    >> The loop could actually be written this way:
    >>
    >> while (c = getc(fp), !feof(fp) && !ferror(fp)) {
    >> ...
    >> }
    >>
    >> But that makes it even uglier.

    >
    > So the shortcut evaluation of C is somewhat different from mathematical
    > logic.


    How is that different from mathematical logic?

    hp


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
    Peter J. Holzer, Sep 21, 2007
    #19
    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. SL_McManus

    A question about EOF

    SL_McManus, Dec 3, 2003, in forum: Perl
    Replies:
    1
    Views:
    468
    Jim Gibson
    Dec 4, 2003
  2. Sacha Korell
    Replies:
    2
    Views:
    14,857
    Mattias Sjögren
    Sep 6, 2003
  3. Kobu
    Replies:
    10
    Views:
    605
    Keith Thompson
    Mar 4, 2005
  4. SpreadTooThin

    ifstream eof not reporting eof?

    SpreadTooThin, Jun 13, 2007, in forum: C++
    Replies:
    10
    Views:
    677
    James Kanze
    Jun 15, 2007
  5. Jan Burse
    Replies:
    67
    Views:
    1,029
    Jan Burse
    Mar 14, 2012
Loading...

Share This Page