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]

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.

 

[John]

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?

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]

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

 

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

 

[Old Wolf]

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.

 

[Al Bowers]

Keith Thompson wrote:




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

 

[Dan Pop]

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

 

[Jesse Meyer]

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.

 

[Keith Thompson]

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

The xor trick should actually work for type unsigned char, as long as
you ensure that you're not swapping a variable with itself.

But really, the best answer to "How do I swap variables without using
a temporary" is "Use a temporary".