comparison error

[Bill Cunningham]

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);
}

 

[Kenny McCormack]

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.

 

[Bill Cunningham]

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

Bill

 

[Keith Thompson]

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.

 

[Morris Keesan]

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.

 

[John Gordon]

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?

 

[Kenny McCormack]

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)

 

[Mark Bluemel]

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.

 

[John Gordon]

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

Boundless optimism?

 

[Bill Cunningham]

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


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]

[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

 

[Barry Schwarz]

[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.

 

[Bill Cunningham]

[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
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