just got myself a copy of K&R...

Discussion in 'C Programming' started by Andy, Nov 6, 2003.

  1. Andy

    Andy Guest

    and so far I'm loving it, I like the the authors don't beat
    around the bush and just come straight out and say what the book
    is sopposed to be. They assume the you have computer experience.

    I'm loving the exercises they really leave you with a sense of freedom
    to do what you want, just follow the rules.

    Just a little rant, I would definitely recommend this book
    to anyone interested in C. Great addition to anyones library.

    cheers....
    Andy, Nov 6, 2003
    #1
    1. Advertising

  2. Andy <> wrote in message news:<jJgqb.33881$>...
    > and so far I'm loving it, I like the the authors don't beat
    > around the bush and just come straight out and say what the book
    > is sopposed to be. They assume the you have computer experience.


    Precisely. K&R is an example of what a technical book should be: No
    digressions, no pandering to those who are not the target audience
    (programmers should know how to use a computer already, IMNSHO), and
    plenty of good examples and clear statements of the rules (that is,
    you aren't left trying to figure out which parts of an example
    illustrate which rules, and you don't mistake nonstandard things the
    author does for good programming).

    >
    > I'm loving the exercises they really leave you with a sense of freedom
    > to do what you want, just follow the rules.


    And that is what programming is, largely: Following the rules and
    creating something within those rules. K&R lays out the rules so well,
    you can use it as a reference manual later on, after you've learned
    the language from it. I've found it a book that ages well, as opposed
    to some more beginner-level texts that are largely worthless once
    you've moved on.

    >
    > Just a little rant, I would definitely recommend this book
    > to anyone interested in C. Great addition to anyones library.


    I agree. Others will be along shortly with more books to recommend
    you. ;)

    The ACCU (Association of C & C++ Users) has some good book reviews on
    their site, and not just on books about C & C++. Here is their book
    review index:

    http://www.accu.org/bookreviews/public/index.htm
    August Derleth, Nov 6, 2003
    #2
    1. Advertising

  3. Andy

    Fao, Sean Guest

    "August Derleth" <> wrote in message
    news:...

    [...]

    > I've found it a book that ages well, as opposed
    > to some more beginner-level texts that are largely worthless once
    > you've moved on.


    When I first started getting into the world of programming, I thought the
    key to learning any language was to learn every single function and operator
    and remembering how they are used (I was no more then 10 or 11 years old at
    the time). K&R is great because, like any good book, it doesn't just throw
    out a bunch of examples without explaining why they work. K&R makes no
    attempt to explain all the functions of the standard library because it
    starts from the ground up, explaining the rules of the language enough to
    let the programmer decide for his or herself what should be used and when.
    Writing functions of my own at the time seemed like some so far, out of this
    galaxy, topic that I had never even thought I could ever learn how.

    The problem with a lot of the beginner level books is that they lead you to
    the same frame of mind that had plagued me in the beginning. If there
    wasn't a chapter in the book dedicated to my specific task, I didn't know
    how to "program" --or was it copy ;-)-- it. It's been a long day so I'm
    probably not making sense anymore but what I'm trying to say is that at some
    point, if a person really wants to learn how to program, the "For Dummy"
    books just won't suffice. And you won't believe how many people refuse to
    accept this. I've had friends that have read the Microsoft _By_ _Example_
    books and knew nothing after completing the book; yet, swore they did. Ask
    them to do anything that isn't in the book and they'll either swear that it
    can't be done or attempt to learn how by getting another book of the same
    kind. Before you know it, the dumbest person at work has the largest book
    colection, reads all of them and doesn't get any smarter.

    Have fun,

    Sean
    Fao, Sean, Nov 6, 2003
    #3
  4. Andy

    Andy Guest

    August Derleth wrote:

    > Andy <> wrote in message
    > news:<jJgqb.33881$>...
    >> and so far I'm loving it, I like the the authors don't beat
    >> around the bush and just come straight out and say what the book
    >> is sopposed to be. They assume the you have computer experience.

    >
    > Precisely. K&R is an example of what a technical book should be: No
    > digressions, no pandering to those who are not the target audience
    > (programmers should know how to use a computer already, IMNSHO), and
    > plenty of good examples and clear statements of the rules (that is,
    > you aren't left trying to figure out which parts of an example
    > illustrate which rules, and you don't mistake nonstandard things the
    > author does for good programming).
    >
    >>
    >> I'm loving the exercises they really leave you with a sense of freedom
    >> to do what you want, just follow the rules.

    >
    > And that is what programming is, largely: Following the rules and
    > creating something within those rules. K&R lays out the rules so well,
    > you can use it as a reference manual later on, after you've learned
    > the language from it. I've found it a book that ages well, as opposed
    > to some more beginner-level texts that are largely worthless once
    > you've moved on.
    >
    >>
    >> Just a little rant, I would definitely recommend this book
    >> to anyone interested in C. Great addition to anyones library.

    >
    > I agree. Others will be along shortly with more books to recommend
    > you. ;)
    >
    > The ACCU (Association of C & C++ Users) has some good book reviews on
    > their site, and not just on books about C & C++. Here is their book
    > review index:
    >
    > http://www.accu.org/bookreviews/public/index.htm


    thanks for the reply.
    glad you agree
    great website.

    also just a little question.
    allot of his examples have the line

    while ((c = getchar()) != EOF)
    how would input in C equal EOF.

    thanks again.
    Andy, Nov 6, 2003
    #4
  5. "Fao, Sean" <-WANT-NO-SPAM> wrote in message news:<Qbzqb.31$>...
    > "August Derleth" <> wrote in message
    > news:...
    >
    > [...]
    >
    > > I've found it a book that ages well, as opposed
    > > to some more beginner-level texts that are largely worthless once
    > > you've moved on.

    >
    > When I first started getting into the world of programming, I thought the
    > key to learning any language was to learn every single function and operator
    > and remembering how they are used (I was no more then 10 or 11 years old at
    > the time).


    Yeah, a common mistake. I think it derives from the elementary-level
    schools focusing on rote memorization instead of problem-solving.
    While rote memorization is useful in programming, it certainly doesn't
    aid the learning of the language beyond a certain level.

    > K&R is great because, like any good book, it doesn't just throw
    > out a bunch of examples without explaining why they work. K&R makes no
    > attempt to explain all the functions of the standard library because it
    > starts from the ground up, explaining the rules of the language enough to
    > let the programmer decide for his or herself what should be used and when.


    Yep. The Standard Library is presented as something most programmers
    will always see it as: A `magical' group of subroutines and magic
    numbers you can call upon after including certain header files. It is
    presented simply as-needed, with the appendix in the back giving a
    short description of all of them in turn.

    Which I think is the best possible way to present the Standard Library
    to a new programmer.

    > Writing functions of my own at the time seemed like some so far, out of this
    > galaxy, topic that I had never even thought I could ever learn how.


    Heh. Very little in programming is magical. Some of it is esoteric and
    badly-documented, some of it is very complex, and some of it is truly
    difficult to understand, but little of it is not doable by someone who
    will invest the effort in learning it.

    And creating subroutines in C is certainly none of the above, except
    doable. ;)

    >
    > The problem with a lot of the beginner level books is that they lead you to
    > the same frame of mind that had plagued me in the beginning. If there
    > wasn't a chapter in the book dedicated to my specific task, I didn't know
    > how to "program" --or was it copy ;-)-- it.


    That's right. That's why books on programming must be written by
    people who are generally intelligent and /do/ have a deep
    understanding of how to put the tricks of the language in context.
    Otherwise, it will be trained seals teaching contextless tricks to
    other trained seals.

    > It's been a long day so I'm
    > probably not making sense anymore but what I'm trying to say is that at some
    > point, if a person really wants to learn how to program, the "For Dummy"
    > books just won't suffice.


    The "For Dummy" books are just that: For dummies. ;) Anyone who can
    gain a deep understanding of a problem will be left behind by the
    sheer ineptness of the texts.

    But think about this: As complex as good programming is, what does the
    sales of the "<Programming Topic> For Dummies" books mean for the
    industry as a whole?

    > And you won't believe how many people refuse to
    > accept this. I've had friends that have read the Microsoft _By_ _Example_
    > books and knew nothing after completing the book; yet, swore they did.


    Hell, I know people who didn't read that book, don't know jack shit,
    and still insist they're intelligent.

    It isn't all the book's fault.

    <big_grin>

    > Ask
    > them to do anything that isn't in the book and they'll either swear that it
    > can't be done or attempt to learn how by getting another book of the same
    > kind.


    And that, my friend, is why software book publishers always look so
    happy.

    And why tech support people always want to price high-powered
    handguns.

    > Before you know it, the dumbest person at work has the largest book
    > colection, reads all of them and doesn't get any smarter.


    Nice of the morons to give us clues like that. I'll know who not to
    bother in the future.

    >
    > Have fun,
    >
    >
    > Sean


    Happy hacking,

    August
    August Derleth, Nov 7, 2003
    #5
  6. Andy

    Alan Connor Guest

    On 6 Nov 2003 12:07:36 -0800, August Derleth <> wrote:
    >
    >
    > Andy <> wrote in message news:<jJgqb.33881$>...
    >> and so far I'm loving it, I like the the authors don't beat
    >> around the bush and just come straight out and say what the book
    >> is sopposed to be. They assume the you have computer experience.

    >
    > Precisely. K&R is an example of what a technical book should be: No
    > digressions, no pandering to those who are not the target audience
    > (programmers should know how to use a computer already, IMNSHO)


    K&R assumes that you already know how to program in another language,
    which is quite a different thing from "knowing how to use a computer".

    --
    Alan C this post ends with w
    q
    Alan Connor, Nov 7, 2003
    #6
  7. Andy wrote:

    > allot of his examples have the line
    >
    > while ((c = getchar()) != EOF)
    > how would input in C equal EOF.


    It wouldn't, ever. EOF is what happens when there is no more input.

    Imagine this. A friend asks you to pull one numbered ball at a time from a
    bucket.

    He asks, "What have you got?" You reply "19". He makes a note somewhere.
    He asks, "What have you got?" You reply "37". He makes a note somewhere.
    He asks, "What have you got?" You reply "12". He makes a note somewhere.
    He asks, "What have you got?" You reply "22". He makes a note somewhere.
    He asks, "What have you got?" You reply "24". He makes a note somewhere.
    He asks, "What have you got?" You reply "41". He makes a note somewhere.
    He asks, "What have you got?" You reply "7". He makes a note somewhere.

    Then he asks, "What have you got?", and you have a look in the bucket, but
    there's nothing left.

    You reply "We seem to have run out".

    He says "How on earth can there be a ball with 'We seem to have run out'
    written on it?"

    How would you answer him?

    Do you now understand EOF?

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
    Richard Heathfield, Nov 7, 2003
    #7
  8. Andy

    Jirka Klaue Guest

    Richard Heathfield wrote:
    > Andy wrote:
    >
    >>allot of his examples have the line
    >>
    >>while ((c = getchar()) != EOF)
    >> how would input in C equal EOF.

    >
    > It wouldn't, ever. EOF is what happens when there is no more input.


    This is the intent, but I think it is not guaranteed, nevertheless.

    for (;;) {
    c = getchar();
    if (feof(f) || ferror(f)) break;
    ...
    }

    Jirka
    Jirka Klaue, Nov 7, 2003
    #8
  9. Andy

    Andy Guest

    Richard Heathfield wrote:

    > Andy wrote:
    >
    >> allot of his examples have the line
    >>
    >> while ((c = getchar()) != EOF)
    >> how would input in C equal EOF.

    >
    > It wouldn't, ever. EOF is what happens when there is no more input.
    >
    > Imagine this. A friend asks you to pull one numbered ball at a time from a
    > bucket.
    >
    > He asks, "What have you got?" You reply "19". He makes a note somewhere.
    > He asks, "What have you got?" You reply "37". He makes a note somewhere.
    > He asks, "What have you got?" You reply "12". He makes a note somewhere.
    > He asks, "What have you got?" You reply "22". He makes a note somewhere.
    > He asks, "What have you got?" You reply "24". He makes a note somewhere.
    > He asks, "What have you got?" You reply "41". He makes a note somewhere.
    > He asks, "What have you got?" You reply "7". He makes a note somewhere.
    >
    > Then he asks, "What have you got?", and you have a look in the bucket, but
    > there's nothing left.
    >
    > You reply "We seem to have run out".
    >
    > He says "How on earth can there be a ball with 'We seem to have run out'
    > written on it?"
    >
    > How would you answer him?
    >
    > Do you now understand EOF?
    >



    Right, so pretty much all of the example programs will run for as long
    as you can input, cause there is nothing you can put in to make it
    EOF. I've had to modify the example programs with something like

    if ((c = getchar()) == -1)
    break;

    or something like that, to actually stop
    the execution of the program.

    is there a better way around this?
    Andy, Nov 7, 2003
    #9
  10. Andy

    Noah Roberts Guest

    Alan Connor wrote:
    > On 6 Nov 2003 12:07:36 -0800, August Derleth <> wrote:
    >
    >>
    >>Andy <> wrote in message news:<jJgqb.33881$>...
    >>
    >>>and so far I'm loving it, I like the the authors don't beat
    >>>around the bush and just come straight out and say what the book
    >>>is sopposed to be. They assume the you have computer experience.

    >>
    >>Precisely. K&R is an example of what a technical book should be: No
    >>digressions, no pandering to those who are not the target audience
    >>(programmers should know how to use a computer already, IMNSHO)

    >
    >
    > K&R assumes that you already know how to program in another language,
    > which is quite a different thing from "knowing how to use a computer".
    >

    I wouldn't say that. Unless I missed it, neither did the authors. K&R
    is very basic and straight forward. It sais in <300 what others take
    >1500 pages to say, and it does it well. I remember as a beginner that

    was the only book that really made much sense to me.

    --
    Noah Roberts
    - "If you are not outraged, you are not paying attention."
    Noah Roberts, Nov 7, 2003
    #10
  11. Andy

    Jirka Klaue Guest

    Andy wrote:
    ....
    > Right, so pretty much all of the example programs will run for as long
    > as you can input, cause there is nothing you can put in to make it
    > EOF. I've had to modify the example programs with something like
    >
    > if ((c = getchar()) == -1)
    > break;
    >
    > or something like that, to actually stop
    > the execution of the program.


    That's bullshit. If EOF is #defined to be -1 (most probably it is),
    your code is exactly the same as the code using EOF. If EOF is not
    -1, your code will not work at all.

    Jirka
    Jirka Klaue, Nov 7, 2003
    #11
  12. Andy

    Andy Guest

    Jirka Klaue wrote:

    > Andy wrote:
    > ...
    >> Right, so pretty much all of the example programs will run for as long
    >> as you can input, cause there is nothing you can put in to make it
    >> EOF. I've had to modify the example programs with something like
    >>
    >> if ((c = getchar()) == -1)
    >> break;
    >>
    >> or something like that, to actually stop
    >> the execution of the program.

    >
    > That's bullshit. If EOF is #defined to be -1 (most probably it is),
    > your code is exactly the same as the code using EOF. If EOF is not
    > -1, your code will not work at all.
    >
    > Jirka


    well obviously EOF is not set to -1 because the program never stops,
    not even with a blank line, or when you put -1, you can hit enter forever
    and the program never stops, the only way to stop it was like that or
    testing for ARRAY, to make sure I didn't input a value past the last
    index point.
    Andy, Nov 7, 2003
    #12
  13. Andy

    Jirka Klaue Guest

    Andy wrote:
    ....
    > well obviously EOF is not set to -1 because the program never stops,


    You don't need to know how EOF is defined, just use the macro EOF.

    > not even with a blank line, or when you put -1, you can hit enter forever
    > and the program never stops, the only way to stop it was like that or
    > testing for ARRAY, to make sure I didn't input a value past the last
    > index point.


    Do you know how to type EOF? Try ^D on unix-like systems and ^Z on DOS/Windows.

    Jirka
    Jirka Klaue, Nov 7, 2003
    #13
  14. Andy

    Andy Guest

    Jirka Klaue wrote:

    > Andy wrote:
    > ...
    >> well obviously EOF is not set to -1 because the program never stops,

    >
    > You don't need to know how EOF is defined, just use the macro EOF.
    >
    >> not even with a blank line, or when you put -1, you can hit enter forever
    >> and the program never stops, the only way to stop it was like that or
    >> testing for ARRAY, to make sure I didn't input a value past the last
    >> index point.

    >
    > Do you know how to type EOF? Try ^D on unix-like systems and ^Z on DOS/Windows.
    >
    > Jirka


    there you thanks, thats pretty much what I was
    looking for. thanks dude.
    Andy, Nov 7, 2003
    #14
  15. On Fri, 07 Nov 2003 11:37:27 -0500, Andy wrote:

    > Jirka Klaue wrote:
    >
    >> Andy wrote:
    >> ...
    >>> Right, so pretty much all of the example programs will run for as long
    >>> as you can input, cause there is nothing you can put in to make it
    >>> EOF. I've had to modify the example programs with something like
    >>>
    >>> if ((c = getchar()) == -1)
    >>> break;
    >>>
    >>> or something like that, to actually stop
    >>> the execution of the program.

    >>
    >> That's bullshit. If EOF is #defined to be -1 (most probably it is),
    >> your code is exactly the same as the code using EOF. If EOF is not
    >> -1, your code will not work at all.
    >>
    >> Jirka

    >
    > well obviously EOF is not set to -1 because the program never stops,
    > not even with a blank line, or when you put -1, you can hit enter forever
    > and the program never stops, the only way to stop it was like that or
    > testing for ARRAY, to make sure I didn't input a value past the last
    > index point.


    Andy, the piece of information that you may be missing is that there
    usually is a way to "type EOF". On my Linux system, that way is to type
    Control-D.

    Also you should indeed use EOF in your code instead of -1. There is no
    guarantee that -1 will be the number used to indicate EOF (although it
    often is).

    -Sheldon
    Sheldon Simms, Nov 7, 2003
    #15
  16. Andy

    Andy Guest

    Sheldon Simms wrote:

    > On Fri, 07 Nov 2003 11:37:27 -0500, Andy wrote:
    >
    >> Jirka Klaue wrote:
    >>
    >>> Andy wrote:
    >>> ...
    >>>> Right, so pretty much all of the example programs will run for as long
    >>>> as you can input, cause there is nothing you can put in to make it
    >>>> EOF. I've had to modify the example programs with something like
    >>>>
    >>>> if ((c = getchar()) == -1)
    >>>> break;
    >>>>
    >>>> or something like that, to actually stop
    >>>> the execution of the program.
    >>>
    >>> That's bullshit. If EOF is #defined to be -1 (most probably it is),
    >>> your code is exactly the same as the code using EOF. If EOF is not
    >>> -1, your code will not work at all.
    >>>
    >>> Jirka

    >>
    >> well obviously EOF is not set to -1 because the program never stops,
    >> not even with a blank line, or when you put -1, you can hit enter forever
    >> and the program never stops, the only way to stop it was like that or
    >> testing for ARRAY, to make sure I didn't input a value past the last
    >> index point.

    >
    > Andy, the piece of information that you may be missing is that there
    > usually is a way to "type EOF". On my Linux system, that way is to type
    > Control-D.
    >
    > Also you should indeed use EOF in your code instead of -1. There is no
    > guarantee that -1 will be the number used to indicate EOF (although it
    > often is).
    >
    > -Sheldon



    thanks man
    that was my problem, couldn't find the EOF input.
    cheers
    Andy, Nov 7, 2003
    #16
  17. Andy

    Mike Wahler Guest

    "Andy" <> wrote in message
    news:XlPqb.39440$...
    > Richard Heathfield wrote:
    >
    > > Andy wrote:
    > >
    > >> allot of his examples have the line
    > >>
    > >> while ((c = getchar()) != EOF)
    > >> how would input in C equal EOF.

    > >
    > > It wouldn't, ever. EOF is what happens when there is no more input.
    > >
    > > Imagine this. A friend asks you to pull one numbered ball at a time from

    a
    > > bucket.
    > >
    > > He asks, "What have you got?" You reply "19". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "37". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "12". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "22". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "24". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "41". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "7". He makes a note somewhere.
    > >
    > > Then he asks, "What have you got?", and you have a look in the bucket,

    but
    > > there's nothing left.
    > >
    > > You reply "We seem to have run out".
    > >
    > > He says "How on earth can there be a ball with 'We seem to have run out'
    > > written on it?"
    > >
    > > How would you answer him?
    > >
    > > Do you now understand EOF?
    > >

    >
    >
    > Right, so pretty much all of the example programs will run for as long
    > as you can input, cause there is nothing you can put in to make it
    > EOF.


    If the input is coming from a file, the OS will generate
    the indication of 'EOF', for keyboard input, most OS's
    have assigned a particular keystroke(s) to mean 'EOF',
    e.g. 'ctrl-Z' for DOS and Windows. This keystroke will
    of course vary among operating systems, if it's available
    at all. Check your OS documentation.


    > I've had to modify the example programs with something like
    >
    > if ((c = getchar()) == -1)
    > break;
    >
    > or something like that, to actually stop
    > the execution of the program.
    >
    > is there a better way around this?


    See above.

    -Mike
    Mike Wahler, Nov 7, 2003
    #17
  18. Andy

    Alan Balmer Guest

    On Fri, 07 Nov 2003 04:18:12 GMT, Alan Connor <> wrote:

    >On 6 Nov 2003 12:07:36 -0800, August Derleth <> wrote:
    >>
    >>
    >> Andy <> wrote in message news:<jJgqb.33881$>...
    >>> and so far I'm loving it, I like the the authors don't beat
    >>> around the bush and just come straight out and say what the book
    >>> is sopposed to be. They assume the you have computer experience.

    >>
    >> Precisely. K&R is an example of what a technical book should be: No
    >> digressions, no pandering to those who are not the target audience
    >> (programmers should know how to use a computer already, IMNSHO)

    >
    >K&R assumes that you already know how to program in another language,
    >which is quite a different thing from "knowing how to use a computer".


    That would be a surprise to the people I know who learned C as their
    first programming language, from K&R.

    --
    Al Balmer
    Balmer Consulting
    Alan Balmer, Nov 7, 2003
    #18
  19. Andy

    CBFalconer Guest

    Andy wrote:
    > Richard Heathfield wrote:
    > > Andy wrote:
    > >
    > >> allot of his examples have the line
    > >>
    > >> while ((c = getchar()) != EOF)
    > >> how would input in C equal EOF.

    > >
    > > It wouldn't, ever. EOF is what happens when there is no more input.
    > >
    > > Imagine this. A friend asks you to pull one numbered ball at a time
    > > from a bucket.
    > >
    > > He asks, "What have you got?" You reply "19". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "37". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "12". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "22". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "24". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "41". He makes a note somewhere.
    > > He asks, "What have you got?" You reply "7". He makes a note somewhere.
    > >
    > > Then he asks, "What have you got?", and you have a look in the bucket,
    > > but there's nothing left.
    > >
    > > You reply "We seem to have run out".
    > >
    > > He says "How on earth can there be a ball with 'We seem to have run out'
    > > written on it?"
    > >
    > > How would you answer him?
    > >
    > > Do you now understand EOF?

    >
    > Right, so pretty much all of the example programs will run for as long
    > as you can input, cause there is nothing you can put in to make it
    > EOF. I've had to modify the example programs with something like
    >
    > if ((c = getchar()) == -1)
    > break;
    >
    > or something like that, to actually stop
    > the execution of the program.
    >
    > is there a better way around this?


    Yes. The above is undefined, and will only work if EOF is
    actually defined to be -1. You should find out how your system
    generates EOF from the keyboard, or redirect stdin to come from a
    file. The usual EOF signals are CTL-D (Unix) and CTL-Z
    (MsDos/Windoze). They may have to be the first characters after a
    '\n'.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Nov 7, 2003
    #19
  20. Jirka Klaue wrote:

    > Richard Heathfield wrote:
    >> Andy wrote:
    >>
    >>>allot of his examples have the line
    >>>
    >>>while ((c = getchar()) != EOF)
    >>> how would input in C equal EOF.

    >>
    >> It wouldn't, ever. EOF is what happens when there is no more input.

    >
    > This is the intent, but I think it is not guaranteed, nevertheless.
    >
    > for (;;) {
    > c = getchar();
    > if (feof(f) || ferror(f)) break;


    The Standard (or rather, the ANSI C draft, because it's the most convenient
    doc to hand right now) says:

    "The getc function returns the next character from the input stream pointed
    to by stream . If the stream is at end-of-file, the end-of-file indicator
    for the stream is set and getc returns EOF . If a read error occurs, the
    error indicator for the stream is set and getc returns EOF.

    4.9.7.6 The getchar function

    [...] The getchar function is equivalent to getc with the argument stdin."


    So if your point was that EOF can be returned for a reason other than
    I'm-all-out-of-data, then you're correct - it can also be returned on
    error. Otherwise, I am not sure what your point is.


    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
    Richard Heathfield, Nov 7, 2003
    #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. newgenre
    Replies:
    1
    Views:
    312
    Kevin Spencer
    Apr 7, 2004
  2. Replies:
    6
    Views:
    30,247
    Diplomat
    Jan 12, 2011
  3. Alex
    Replies:
    2
    Views:
    1,206
  4. grocery_stocker

    I think the question I just posted got lost.

    grocery_stocker, Jun 3, 2005, in forum: C Programming
    Replies:
    3
    Views:
    303
    Clark S. Cox III
    Jun 3, 2005
  5. Replies:
    26
    Views:
    2,095
    Roland Pibinger
    Sep 1, 2006
Loading...

Share This Page