getchar() and EOF confusion

[arnuld]

Mostly when I want to take input from stdin I use getchar() but I get this
from man page itself:

"If the integer value returned by getchar() is stored into a variable of
type char and then compared against the integer constant EOF, the
comparison may never succeed, because sign-extension of a variable of type
char on widening to integer is implementation-defined"
while( EOF != (ch = getchar()) ) ....
I use it like that. Can I run into problems with that ?


--
www.lispmachine.wordpress.com
my email is @ the above blog.

[Richard Heathfield]

arnuld said:

Mostly when I want to take input from stdin I use getchar() but I get
this from man page itself:

"If the integer value returned by getchar() is stored into a variable
of
type char and then compared against the integer constant EOF, the
comparison may never succeed, because sign-extension of a variable of
type char on widening to integer is implementation-defined"
while( EOF != (ch = getchar()) ) ....
I use it like that. Can I run into problems with that ?

You can run into problems with anything - but the above is a good idiom.
Ensure that ch has type int.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[arnuld]

On Wed, 15 Oct 2008, Richard Heathfield wrote:

You can run into problems with anything - but the above is a good idiom.
Ensure that ch has type int.

Oh.. thats why K&R2 uses "int ch" , thanks :)

[Barry Schwarz]

On Wed, 15 Oct 2008 09:47:14 +0500, arnuld <su*****@invali d.address>
wrote:

>Mostly when I want to take input from stdin I use getchar() but I get this
from man page itself:

"If the integer value returned by getchar() is stored into a variable of
type char and then compared against the integer constant EOF, the
comparison may never succeed, because sign-extension of a variable of type
char on widening to integer is implementation-defined"
while( EOF != (ch = getchar()) ) ....
I use it like that. Can I run into problems with that ?

getchar treats the data it obtains from the stream as unsigned. EOF
is guaranteed to be negative. Can you see where this leads?

--
Remove del for email

[danmath06]

arnuld <sunr...@invali d.addresswrote:

Mostly when I want to take input from stdin I use getchar() but I get this
from man page itself:

"If the integer value returned by getchar() is stored into a variable of
type char and then compared against the integer constant EOF, the
comparison may never succeed, because sign-extension of a variable of type
char on widening to integer is implementation-defined"

while( EOF != (ch = getchar()) ) ....

I use it like that. Can I run into problems with that ?

Yes, if ch is not an int. The prototype for getchar() is: "int
getchar(void);" . So you should use an int to hold the return from
getchar();

[Peter Nilsson]

arnuld <sunr...@invali d.addresswrote:

Mostly when I want to take input from stdin I use
getchar() but I get this from man page itself: *

* "If the *integer value returned by getchar() is
stored into a variable of*type char and then
compared against the integer constant EOF, the
* *comparison may never succeed, because sign-
extension of a variable of type*char on
widening to integer is implementation-defined"

The manual is poorly written. Integral promotion
is well defined and will always be value preserving
in the case of char values.

What is implementation defined is whether plain char
is signed or unsigned, but that too is mostly
incidental.

* * *while( EOF != (ch = getchar()) ) ....

I use it like that. Can I run into problems with that ?

Did you read the FAQ?

http://c-faq.com/stdio/getcharc.html

--
Peter

[Pranav]

Then does reading a character sized data into a integer type of data
variable do cause an issue in the porting of the code ??

[Nate Eldredge]

Pranav <pr*******@gmai l.comwrites:

Then does reading a character sized data into a integer type of data
variable do cause an issue in the porting of the code ??

I'm not sure I understand what you mean. Can you give an example of the
kind of code you have in mind?

[arnuld]

On Tue, 14 Oct 2008 23:00:57 -0700, Pranav wrote:

Then does reading a character sized data into a integer type of data
variable do cause an issue in the porting of the code ??

No, as every character is converted into an integer at compilation. Right
clc folks ? ( or you think I am confusing ASCII table with compiler ?)

--
www.lispmachine.wordpress.com
my email is @ the above blog.
Google Groups is UnBlocked now :)

[Keith Thompson]

arnuld <su*****@invali d.addresswrites :

>On Tue, 14 Oct 2008 23:00:57 -0700, Pranav wrote:
Then does reading a character sized data into a integer type of data
variable do cause an issue in the porting of the code ??

No, as every character is converted into an integer at compilation. Right
clc folks ? ( or you think I am confusing ASCII table with compiler ?)

Pranav was talking about run-time input, not compilation.

Note that type char is an integer type. It's important to distinguish
between an integer type (of which there are several, including char,
int, unsigned long, etc.) and the specific integer type called "int".
The name "int" was obviously formed as an abbreviation of the word
"integer", but they mean different things.

getchar() attempts to read the next character from stdin. If it
succeeds, it treats the character as a value of type unsigned char,
and then converts the resulting unsigned char value to int. Since all
unsigned char values are non-negative, the result of the conversion is
non-negative. If it fails (either because there's no more input or
because of some error), it returns the int value EOF, which, since
it's negative, is distinct from any valid character value. (Plain
char may be either signed or unsigned -- but getchar() doesn't use
plain char.)

The answer to Pranav's questions is no, this doesn't cause any
problems with porting code.

Well, mostly. Some exotic machines might have sizeof(int)==1 (which
can happen only if char is at least 16 bits). On such a system, it
can be difficult to distinguish between EOF (typically an int value of
-1) and a valid character with the unsigned char value 0xffff, which
when converted to int is likely to yield -1.

You're unlikely to run into this in practice. Machines with this
characteristic are typically DSPs (digital signal processors) which
typically have freestanding C implementations , so stdio.h might not
even be available. But if you want your code to be 100% portable, you
can first check whether the result returned by getchar() is equal to
EOF, and then check whether either feof() or ferror() returns a true
value. In practice, we don't generally bother.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"