if EOF = -1, can't a valid character == EOF and cause problems?

[Kobu]

My question is about EOF (which is (int)-1 on the
implementation I use). Type char on my implementation
is 'signed' too.

How is it that the input library functions that return
EOF can be used properly if something like ASCII 255
is read from the input file? 255 would be returned as -1,
and would be compared against EOF and cause problems.

What's the point of declaring a int to hold the return
value from these functions, when a char(on my implementation)
can represent a -1(EOF on my representation) also?

Example;

char c_char;
while( (c_char = getchar()) != EOF )
{ /* something */ }

will work just as *badly* as:

int c_int;
while( (c_int= getchar()) != EOF )
{ /* something */ }
I'm not complaining about the AMBIGUITY of
(int)EOF vs.(int)(Ascii 255 returned as -1)
but wondering why people suggent capturing the
return value from functions like getchar into
an int, when the int doesn't help us get rid
of this ambiguous case?

I've tried to research this to death and wrap my
mind around a possible answer, but I have failed
miserably. I need someone to help me turn on the
flickering lightbulb.

Much thanks in advance

[Joona I Palaste]

Kobu <ko********@gma il.com> scribbled the following:

My question is about EOF (which is (int)-1 on the
implementation I use). Type char on my implementation
is 'signed' too. How is it that the input library functions that return
EOF can be used properly if something like ASCII 255
is read from the input file? 255 would be returned as -1,
and would be compared against EOF and cause problems. What's the point of declaring a int to hold the return
value from these functions, when a char(on my implementation)
can represent a -1(EOF on my representation) also?
You just answered your own question. The functions return int
precisely because of the need to distinguish between -1 and 255.
Example; char c_char;
while( (c_char = getchar()) != EOF )
{ /* something */ } will work just as *badly* as: int c_int;
while( (c_int= getchar()) != EOF )
{ /* something */ }
No, it won't. The second version will work much better. You see,
although as a signed char, 255 is the same as -1, as a signed int,
255 is 255 and -1 is -1, and never the twain shall meet.
I'm not complaining about the AMBIGUITY of
(int)EOF vs.(int)(Ascii 255 returned as -1)
but wondering why people suggent capturing the
return value from functions like getchar into
an int, when the int doesn't help us get rid
of this ambiguous case?
But it does help.
I've tried to research this to death and wrap my
mind around a possible answer, but I have failed
miserably. I need someone to help me turn on the
flickering lightbulb. Much thanks in advance

I hope I have been of help.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"How can we possibly use sex to get what we want? Sex IS what we want."
- Dr. Frasier Crane

[John]

On 3 Mar 2005 13:10:56 -0800, "Kobu" <ko********@gma il.com> wrote:

My question is about EOF (which is (int)-1 on the
implementati on I use). Type char on my implementation
is 'signed' too.

How is it that the input library functions that return
EOF can be used properly if something like ASCII 255
is read from the input file? 255 would be returned as -1,
and would be compared against EOF and cause problems.

What's the point of declaring a int to hold the return
value from these functions, when a char(on my implementation)
can represent a -1(EOF on my representation) also?

In the case where integers and characters are not the same
length, you'll find that char 255 appears as an integer 255
and -1 appears as -1.

This is a widely used interview question, so read up on it.

Also learn how to swap bytes without using a temporary, how
to implement atoi() and how to reverse a list and you're mostly there!

Now, there are 5 pirates ....

[Keith Thompson]

"Kobu" <ko********@gma il.com> writes:

My question is about EOF (which is (int)-1 on the
implementation I use). Type char on my implementation
is 'signed' too.

How is it that the input library functions that return
EOF can be used properly if something like ASCII 255
is read from the input file? 255 would be returned as -1,
and would be compared against EOF and cause problems.

What's the point of declaring a int to hold the return
value from these functions, when a char(on my implementation)
can represent a -1(EOF on my representation) also?

Example;

char c_char;
while( (c_char = getchar()) != EOF )
{ /* something */ }

will work just as *badly* as:

int c_int;
while( (c_int= getchar()) != EOF )
{ /* something */ }

getchar() returns the next character from stdin *as an unsigned char*
converted to int. If the character read has the value 255, getchar()
will return 255, even if plain char is signed. At end-of-file,
getchar() returns the distinct value EOF (-1 on your system).

If you assign the result of getchar() to a variable of type
char, you lose the ability to distinguish between 255 and -1.

(There's still a potential problem on exotic systems where char and
int are the same size, but you almost certainly don't need to worry
about that.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <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.

[DHOLLINGSWORTH2]

Actually I think you've confused the Control Flags value -1 for the Data
being read. You can actually read both at the same time. ( 0x0ff, and EOF
flag)

"Kobu" <ko********@gma il.com> wrote in message
news:11******** **************@ l41g2000cwc.goo glegroups.com.. .

My question is about EOF (which is (int)-1 on the
implementation I use). Type char on my implementation
is 'signed' too.

How is it that the input library functions that return
EOF can be used properly if something like ASCII 255
is read from the input file? 255 would be returned as -1,
and would be compared against EOF and cause problems.

What's the point of declaring a int to hold the return
value from these functions, when a char(on my implementation)
can represent a -1(EOF on my representation) also?

Example;

char c_char;
while( (c_char = getchar()) != EOF )
{ /* something */ }

will work just as *badly* as:

int c_int;
while( (c_int= getchar()) != EOF )
{ /* something */ }
I'm not complaining about the AMBIGUITY of
(int)EOF vs.(int)(Ascii 255 returned as -1)
but wondering why people suggent capturing the
return value from functions like getchar into
an int, when the int doesn't help us get rid
of this ambiguous case?

I've tried to research this to death and wrap my
mind around a possible answer, but I have failed
miserably. I need someone to help me turn on the
flickering lightbulb.

Much thanks in advance

[Old Wolf]

DHOLLINGSWORTH2 wrote:

Actually I think you've confused the Control Flags value -1 for the Data being read. You can actually read both at the same time. ( 0x0ff, and EOF flag)

Please don't top-post, and please don't answer questions
if you have no idea what you are talking about.

[pete]

Keith Thompson wrote:

(There's still a potential problem on exotic systems where char and
int are the same size, but you almost certainly don't need to worry
about that.)

Use feof,
to distinguish cases when getchar is supposed to return EOF
from cases where there is an end of file condition.

--
pete

[Al Bowers]

pete wrote:

Keith Thompson wrote:

(There's still a potential problem on exotic systems where char and
int are the same size, but you almost certainly don't need to worry
about that.)

Use feof,
to distinguish cases when getchar is supposed to return EOF
from cases where there is an end of file condition.

In C, EOF is only indicated after an input routine has tried to read,
and has reached end-of-file. So the input function (getchar in this
case) must first reach the end of the file and return EOF and the
end-of-file indicator for the stream is set. Calling function
feof before the input function has reached the end of the file will
not indicate that the next getchar call will return EOF.
Read faq question 12.2:
http://www.eskimo.com/~scs/C-faq/q12.2.html
--
Al Bowers
Tampa, Fl USA
mailto: xa******@myrapi dsys.com (remove the x to send email)
http://www.geocities.com/abowers822/

[Dan Pop]

In <42**********@m indspring.com> pete <pf*****@mindsp ring.com> writes:

Keith Thompson wrote:

(There's still a potential problem on exotic systems where char and
int are the same size, but you almost certainly don't need to worry
about that.)

Use feof,
to distinguish cases when getchar is supposed to return EOF
from cases where there is an end of file condition.

1. If there is an end of file condition, getchar() is supposed to
return EOF, so there is no distinction.

2. If you don't want to rely on EOF, you have to use both ferror() and
feof().

Dan
--
Dan Pop <Da*****@ifh.de >

[Jesse Meyer]

John <jo*******@hotm ail.com> wrote:

Also learn how to swap bytes without using a temporary

If you figure out how to do it in standard C, I'd be curious to
know.

--
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925