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]

In article <4ea9f052$0$19267$bbae...@news.suddenlink.net>,

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

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

"Bill Cunningham" <nos...@nspam.invalid> 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) ks...@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Morris Keesan]

On Thu, 27 Oct 2011 21:08:55 -0400, Keith Thompson <ks...@mib.org> wrote:

> "Bill Cunningham" <nos...@nspam.invalid> 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 -- mke...@post.harvard.edu

[John Gordon]

In <4ea9f052$0$19267$bbae...@news.suddenlink.net> "Bill Cunningham" <nos...@nspam.invalid> 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
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

[Kenny McCormack]

In article <lnaa8ln...@nuthaus.mib.org>,

Keith Thompson <ks...@mib.org> wrote:
>"Bill Cunningham" <nos...@nspam.invalid> 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)

[Mark Bluemel]

On 10/28/2011 03:09 AM, John Gordon wrote:
> In<4ea9f052$0$19267$bbae...@news.suddenlink.net> "Bill Cunningham"<nos...@nspam.invalid> 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.

[John Gordon]

In <j8dlno$je$1...@dont-email.me> Mark Bluemel <mark_b...@pobox.com> writes:

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

Boundless optimism?

[Joe Wright]

On 10/28/2011 10:20, John Gordon wrote:
> In<j8dlno$je$1...@dont-email.me> Mark Bluemel<mark_b...@pobox.com> writes:
>
>> I don't think you're new here. So why do you believe responding to Bill
>> has any value?
>
> Boundless optimism?
>

I'm sure all of the responses are appreciated by Bill.

--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."

[Bill Cunningham]

Morris Keesan wrote:
> On Thu, 27 Oct 2011 21:08:55 -0400, Keith Thompson <ks...@mib.org>
> wrote:
>> "Bill Cunningham" <nos...@nspam.invalid> 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]

"Morris Keesan" <mke...@post.harvard.edu> wrote in message
news:op.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

[Barry Schwarz]

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

[Bill Cunningham]

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