comparison error

Discussion in 'C Programming' started by Bill Cunningham, Oct 28, 2011.

  1. I get a comparison error here and I see the problem but don't know how
    to fix it. It's been so long. Here's the code.

    #include <stdio.h>

    int main(int argc, char **argv)
    {
    if (argc != 2) {
    perror("argc error");
    return -1;
    }
    int i, a;
    i = a = 0;
    FILE *fp;
    if ((fp = fopen(argv[1], "r+")) == EOF) {

    /* right here above argv[1] is a char ** and the first parameter of fopen is
    char *. This is what I believe the problem is. How should I fix this?
    */
    perror("fopen error");
    return -1;
    }
    for (; i != EOF; ++i) {
    fgetc(fp);
    fputc(a, fp);
    return 0;
    }
    fclose(fp);
    }
    Bill Cunningham, Oct 28, 2011
    #1
    1. Advertising

  2. In article <4ea9f052$0$19267$>,
    Bill Cunningham <> wrote:
    > I get a comparison error here and I see the problem but don't know how
    >to fix it. It's been so long. Here's the code.
    >
    >#include <stdio.h>
    >
    >int main(int argc, char **argv)
    >{
    > if (argc != 2) {
    > perror("argc error");
    > return -1;
    > }
    > int i, a;
    > i = a = 0;
    > FILE *fp;
    > if ((fp = fopen(argv[1], "r+")) == EOF) {
    >
    >/* right here above argv[1] is a char ** and the first parameter of fopen is
    >char *. This is what I believe the problem is. How should I fix this?
    >*/
    > perror("fopen error");
    > return -1;
    > }
    > for (; i != EOF; ++i) {
    > fgetc(fp);
    > fputc(a, fp);
    > return 0;
    > }
    > fclose(fp);
    >}
    >
    >


    Masterful trolling! Well done, sir!

    Should keep the human compilers busy for weeks.

    --
    "Remember when teachers, public employees, Planned Parenthood, NPR and PBS
    crashed the stock market, wiped out half of our 401Ks, took trillions in
    TARP money, spilled oil in the Gulf of Mexico, gave themselves billions in
    bonuses, and paid no taxes? Yeah, me neither."
    Kenny McCormack, Oct 28, 2011
    #2
    1. Advertising

  3. Oop. Sorry for the trouble. I need to start paying attention more to my
    docs. I see the comparison problem now.

    Bill
    Bill Cunningham, Oct 28, 2011
    #3
  4. "Bill Cunningham" <> writes:
    > Oop. Sorry for the trouble. I need to start paying attention more to my
    > docs. I see the comparison problem now.


    By all means, don't bother to tell us what the problem was. No point in
    anyone else learning anything.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Oct 28, 2011
    #4
  5. On Thu, 27 Oct 2011 21:08:55 -0400, Keith Thompson <> wrote:

    > "Bill Cunningham" <> writes:
    >> Oop. Sorry for the trouble. I need to start paying attention more to my
    >> docs. I see the comparison problem now.

    >
    > By all means, don't bother to tell us what the problem was. No point in
    > anyone else learning anything.
    >


    Bill implied that the error was in the line:
    > if ((fp = fopen(argv[1], "r+")) == EOF) {


    where, of course, he's comparing a (FILE *) to an (int)


    ....

    Also providing some amusement is the code

    > for (; i != EOF; ++i) {
    > fgetc(fp);
    > fputc(a, fp);
    > return 0;
    > }


    which attempts to write a single nul byte somewhere in the file fp, and
    then exit. However, unless the file was initially empty, this code
    violates a constraint, since input (fgetc) is followed immediately by
    output (fputc) without any intervening file-positioning operation.
    (7.19.5.3, paragraph 6).
    Bill seems to be off his meds again, and I have no real idea what this
    code was intended to do. Even if he meant to iterate through the loop
    until ((a = fgetc(fp)) == EOF), I can't guess what he intended by
    writing a back to the same file.

    The body of the "loop" is only executed once, which is a good thing,
    otherwise it would run through thousands of iterations, at least, until
    i == INT_MAX, at which point incrementing invokes (undefined? unspecified?)
    behavior. On the platforms I'm most familiar with, I think that adding
    one to INT_MAX is likely to result in INT_MIN, and thousands of iterations
    later, i would eventually equal -1, which is the usual definition of EOF.

    --
    Morris Keesan --
    Morris Keesan, Oct 28, 2011
    #5
  6. Bill Cunningham

    John Gordon Guest

    In <4ea9f052$0$19267$> "Bill Cunningham" <> writes:

    > I get a comparison error here and I see the problem but don't know how
    > to fix it. It's been so long. Here's the code.


    Whenever you ask for help with an error, it's best to post the exact
    error you get. Just telling us "comparison error" is very vague.

    > if ((fp = fopen(argv[1], "r+")) == EOF) {


    You probably meant to compare to NULL here, not EOF.

    > /* right here above argv[1] is a char ** and the first parameter of fopen is
    > char *. This is what I believe the problem is. How should I fix this?
    > */


    argv is a char **, but argv[1] is a char *.

    > for (; i != EOF; ++i) {
    > fgetc(fp);
    > fputc(a, fp);
    > return 0;
    > }


    Why on earth is this in a loop? The return statement guarantees it will
    only execute one loop iteration.

    Also, "a" never gets a new value after being initialized to zero. Why?

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
    John Gordon, Oct 28, 2011
    #6
  7. In article <>,
    Keith Thompson <> wrote:
    >"Bill Cunningham" <> writes:
    >> Oop. Sorry for the trouble. I need to start paying attention more to my
    >> docs. I see the comparison problem now.

    >
    >By all means, don't bother to tell us what the problem was. No point in
    >anyone else learning anything.


    Agreed. (Amazing that, me & Kiki agreeing on something. Must be true, then)

    --
    But the Bush apologists hope that you won't remember all that. And they
    also have a theory, which I've been hearing more and more - namely,
    that President Obama, though not yet in office or even elected, caused the
    2008 slump. You see, people were worried in advance about his future
    policies, and that's what caused the economy to tank. Seriously.

    (Paul Krugman - Addicted to Bush)
    Kenny McCormack, Oct 28, 2011
    #7
  8. Bill Cunningham

    Mark Bluemel Guest

    On 10/28/2011 03:09 AM, John Gordon wrote:
    > In<4ea9f052$0$19267$> "Bill Cunningham"<> writes:
    >
    >> I get a comparison error here and I see the problem but don't know how
    >> to fix it. It's been so long. Here's the code.

    >
    > Whenever you ask for help with an error, it's best to post the exact
    > error you get. Just telling us "comparison error" is very vague.
    >
    >> if ((fp = fopen(argv[1], "r+")) == EOF) {

    >
    > You probably meant to compare to NULL here, not EOF.
    >
    >> /* right here above argv[1] is a char ** and the first parameter of fopen is
    >> char *. This is what I believe the problem is. How should I fix this?
    >> */

    >
    > argv is a char **, but argv[1] is a char *.
    >
    >> for (; i != EOF; ++i) {
    >> fgetc(fp);
    >> fputc(a, fp);
    >> return 0;
    >> }

    >
    > Why on earth is this in a loop? The return statement guarantees it will
    > only execute one loop iteration.
    >
    > Also, "a" never gets a new value after being initialized to zero. Why?


    I don't think you're new here. So why do you believe responding to Bill
    has any value? I suppose it may possibly warn any unwary reader that
    Bill's code is not a helpful model, but if you need to be told that,
    perhaps you need to simply read K&R or something.
    Mark Bluemel, Oct 28, 2011
    #8
  9. Bill Cunningham

    John Gordon Guest

    In <j8dlno$je$> Mark Bluemel <> writes:

    > I don't think you're new here. So why do you believe responding to Bill
    > has any value?


    Boundless optimism?

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
    John Gordon, Oct 28, 2011
    #9
  10. Morris Keesan wrote:
    > On Thu, 27 Oct 2011 21:08:55 -0400, Keith Thompson <>
    > wrote:
    >> "Bill Cunningham" <> writes:
    >>> Oop. Sorry for the trouble. I need to start paying attention more
    >>> to my docs. I see the comparison problem now.

    >>
    >> By all means, don't bother to tell us what the problem was. No
    >> point in anyone else learning anything.
    >>

    >
    > Bill implied that the error was in the line:
    >> if ((fp = fopen(argv[1], "r+")) == EOF) {

    >
    > where, of course, he's comparing a (FILE *) to an (int)


    I forgot NULL was needed yes.

    >
    > Also providing some amusement is the code
    >
    >> for (; i != EOF; ++i) {
    >> fgetc(fp);
    >> fputc(a, fp);
    >> return 0;
    >> }

    >
    > which attempts to write a single nul byte somewhere in the file fp,
    > and then exit. However, unless the file was initially empty, this
    > code violates a constraint, since input (fgetc) is followed
    > immediately by output (fputc) without any intervening
    > file-positioning operation. (7.19.5.3, paragraph 6).
    > Bill seems to be off his meds again, and I have no real idea what this
    > code was intended to do. Even if he meant to iterate through the loop
    > until ((a = fgetc(fp)) == EOF), I can't guess what he intended by
    > writing a back to the same file.
    >
    > The body of the "loop" is only executed once, which is a good thing,
    > otherwise it would run through thousands of iterations, at least,
    > until i == INT_MAX, at which point incrementing invokes (undefined?
    > unspecified?) behavior. On the platforms I'm most familiar with, I
    > think that adding one to INT_MAX is likely to result in INT_MIN, and
    > thousands of iterations later, i would eventually equal -1, which is
    > the usual definition of EOF.


    This is embarrassing now that I remember how to do what I'm wanting. I
    forgot it's been so long. I need two FILE * streams. One to read and one to
    write. I was thinking I could do it with one. And two calls to fopen one to
    strictly read and one to write. If I'm thinking right. Then I'll need a file
    descriptor of 32 bits as an int and try this.

    while((a=fgetc(fp)!=EOF)
    fputsc(a,fp);

    Sound right?

    Bill
    Bill Cunningham, Oct 28, 2011
    #10
  11. "Morris Keesan" <> wrote in message
    news:eek:p.v31f8wyf5qv6o3@toshiba-laptop...

    [snip]

    > Bill seems to be off his meds again, and I have no real idea what this
    > code was intended to do. Even if he meant to iterate through the loop
    > until ((a = fgetc(fp)) == EOF), I can't guess what he intended by
    > writing a back to the same file.


    [snip]

    I am looking to write something like nano. Or the old pico. Maybe I
    should be using stdout and stdin instead of writing code that would just act
    as *nix's cp command. I guess that's just about the jist of it. And it's
    going to take a lot more than just opening and closing files. There will
    need to be a buffer for entering text. Some other type of API might be
    needed other than just c89-99.

    Bill
    Bill Cunningham, Oct 29, 2011
    #11
  12. On Fri, 28 Oct 2011 22:35:33 -0400, "Bill Cunningham"
    <> wrote:

    >
    >"Morris Keesan" <> wrote in message
    >news:eek:p.v31f8wyf5qv6o3@toshiba-laptop...
    >
    >[snip]
    >
    >> Bill seems to be off his meds again, and I have no real idea what this
    >> code was intended to do. Even if he meant to iterate through the loop
    >> until ((a = fgetc(fp)) == EOF), I can't guess what he intended by
    >> writing a back to the same file.

    >
    >[snip]
    >
    > I am looking to write something like nano. Or the old pico. Maybe I
    >should be using stdout and stdin instead of writing code that would just act
    >as *nix's cp command. I guess that's just about the jist of it. And it's
    >going to take a lot more than just opening and closing files. There will
    >need to be a buffer for entering text. Some other type of API might be
    >needed other than just c89-99.


    It was bad enough when you would take haphazard stabs at coding but
    now you seem to be generating sentences at random.

    --
    Remove del for email
    Barry Schwarz, Oct 30, 2011
    #12
  13. Barry Schwarz wrote:
    > On Fri, 28 Oct 2011 22:35:33 -0400, "Bill Cunningham"
    > <> wrote:
    >
    >>
    >> "Morris Keesan" <> wrote in message
    >> news:eek:p.v31f8wyf5qv6o3@toshiba-laptop...
    >>
    >> [snip]
    >>
    >>> Bill seems to be off his meds again, and I have no real idea what
    >>> this code was intended to do. Even if he meant to iterate through
    >>> the loop until ((a = fgetc(fp)) == EOF), I can't guess what he
    >>> intended by writing a back to the same file.

    >>
    >> [snip]
    >>
    >> I am looking to write something like nano. Or the old pico. Maybe
    >> I should be using stdout and stdin instead of writing code that
    >> would just act as *nix's cp command. I guess that's just about the
    >> jist of it. And it's going to take a lot more than just opening and
    >> closing files. There will need to be a buffer for entering text.
    >> Some other type of API might be needed other than just c89-99.

    >
    > It was bad enough when you would take haphazard stabs at coding but
    > now you seem to be generating sentences at random.


    "I can't guess what he
    >>> intended by writing a back to the same file."


    Was the statement I was docusing on. It's sounds a little like "What is
    he intending to do." So I thought I'd write a ΒΆ trying to explain that. But
    I have looked at nano's source and it seems to have a lot of unix sys calls
    rather than c?9 in it.

    HTH

    Bill
    Bill Cunningham, Oct 30, 2011
    #13
    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. PW

    Number comparison error

    PW, May 23, 2004, in forum: ASP General
    Replies:
    7
    Views:
    180
    Roland Hall
    May 25, 2004
  2. Greg Willits

    Error in Ruby text comparison?

    Greg Willits, Oct 27, 2007, in forum: Ruby
    Replies:
    6
    Views:
    128
    Devi Web Development
    Oct 27, 2007
  3. Jake Alucard

    Comparison error

    Jake Alucard, Oct 20, 2010, in forum: Ruby
    Replies:
    2
    Views:
    115
    Rajinder Yadav
    Oct 20, 2010
  4. Deepu
    Replies:
    1
    Views:
    217
    ccc31807
    Feb 7, 2011
  5. bjjnova
    Replies:
    1
    Views:
    89
    John G Harris
    Apr 25, 2006
Loading...

Share This Page