Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > cannot understand the character handling Program

Reply
Thread Tools

cannot understand the character handling Program

 
 
Gladiator
Guest
Posts: n/a
 
      01-04-2006
When I am trying to execute a program from "The C Programming Language"
by Dennis Ritchie, I tried to run the following program.I am using
Dev++ as a compiler software. The
Program is presented below.


#include <stdio.h>
main()
{
long nc;

nc = 0;
while(getchar() != EOF)
++nc;
printf("%1d\n",nc);
}

Whatever I am typing, It is displayed in the black window. I am not
able to reach the EOF as specified in the While statement even after
giving a considerable inputs. I have 2 questions.

1st is I simply cannot understand the logic of the program
even after going through it.
Whatever the input we are typing in is appearing in the window. Is
there any where the data is being stored. I would be thankful if
someone could explain the use of the program in layman's language.

2nd question is, we are using the EOF to compare it with a
value. Is it necessary to specify the EOF value before we use it in a
comparison?. One way what i could think is the EOF value may be the
maximum value that the variable can hold ( In this "Long"). But I am
not sure about it.

Please help me to understand it.

 
Reply With Quote
 
 
 
 
M.B
Guest
Posts: n/a
 
      01-04-2006

Gladiator wrote:
> When I am trying to execute a program from "The C Programming Language"
> by Dennis Ritchie, I tried to run the following program.I am using
> Dev++ as a compiler software. The
> Program is presented below.
>
>
> #include <stdio.h>
> main()
> {
> long nc;
>
> nc = 0;
> while(getchar() != EOF)
> ++nc;
> printf("%1d\n",nc);
> }
>
> Whatever I am typing, It is displayed in the black window. I am not
> able to reach the EOF as specified in the While statement even after
> giving a considerable inputs. I have 2 questions.
>

first of all understand the program.
this takes input from standard input (keyboard by default - getchar
does it) . count the number of characters typed and displays the count
on end of input (in standard output - terminal). the end of input is
EOF (end of file). I am not sure of DOS but in unix control+d gives EOF


> 1st is I simply cannot understand the logic of the program
> even after going through it.
> Whatever the input we are typing in is appearing in the window. Is
> there any where the data is being stored. I would be thankful if
> someone could explain the use of the program in layman's language.
>
> 2nd question is, we are using the EOF to compare it with a
> value. Is it necessary to specify the EOF value before we use it in a
> comparison?. One way what i could think is the EOF value may be the
> maximum value that the variable can hold ( In this "Long"). But I am
> not sure about it.
>

EOF is not any maximum defined by size of anything. it indicated that
thatere are no more input available. it is defined in stdio . h and in
unix it is ctrl+d.
EOF is present at the end of all files (atleast in unix)

if ctrl+d dont work in ur OS for EOF pls refer to OS manual for it

> Please help me to understand it.


 
Reply With Quote
 
 
 
 
Thad Smith
Guest
Posts: n/a
 
      01-04-2006
Gladiator wrote:

> #include <stdio.h>
> main()
> {
> long nc;
>
> nc = 0;
> while(getchar() != EOF)
> ++nc;
> printf("%1d\n",nc);
> }
>
> Whatever I am typing, It is displayed in the black window. I am not
> able to reach the EOF as specified in the While statement even after
> giving a considerable inputs.


The program loops as long as another character can be obtained from the
input stream stdin. If you are using keyboard input (in the absence of
piping from a file or other program), it continues to accept characters
until you somehow terminate the input stream. The termination is OS
specific, usually a special key or key sequence.

> 1st is I simply cannot understand the logic of the program
> even after going through it.
> Whatever the input we are typing in is appearing in the window. Is
> there any where the data is being stored.


Not by your program.

> I would be thankful if
> someone could explain the use of the program in layman's language.


getchar() reads the next input character from the standard input stream.
If there are no more characters, EOF (for End of File) is returned
instead of a character. Each time the return value is not EOF, nc is
incremented.

When there no more characters, the loop terminates and the printf
statement should print the number of characters read. Your program uses
an incorrect format, %1d, which should be %ld, because the variable nc
is a long int.

> 2nd question is, we are using the EOF to compare it with a
> value. Is it necessary to specify the EOF value before we use it in a
> comparison?.


Yes. Fortunately, that is already done is <stdio.h>, which you included
prior to using EOF.

> One way what i could think is the EOF value may be the
> maximum value that the variable can hold ( In this "Long"). But I am
> not sure about it.


EOF is an integer value that is separate from all input character values
converted to an unsigned int (we are handling simple type char
characters here, not wide characters). Typically it is -1, but it may
vary from one implementation to another.

--
Thad
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-04-2006
"M.B" <> writes:
> Gladiator wrote:

[snip]
>> 2nd question is, we are using the EOF to compare it with a
>> value. Is it necessary to specify the EOF value before we use it in a
>> comparison?. One way what i could think is the EOF value may be the
>> maximum value that the variable can hold ( In this "Long"). But I am
>> not sure about it.
>>

> EOF is not any maximum defined by size of anything. it indicated that
> thatere are no more input available. it is defined in stdio . h and in
> unix it is ctrl+d.
> EOF is present at the end of all files (atleast in unix)
>
> if ctrl+d dont work in ur OS for EOF pls refer to OS manual for it


Both of you have misunderstood what EOF is all about.

Each file (including stdin) has an end-of-file indicator. This isn't
a character or a value, it's a condition; it indicates that the last
attempt to read from the file failed because it had reached the end of
the file.

EOF is a macro defined in <stdio.h>. It specifies the value that will
be returned by certain input functions, such as getchar(), on an
end-of-file or error condition. The value of EOF isn't specified by
the standard except that it's a negative integer (it's typically -1).
The getchar() function attempts to read a character. If it was
successful, it returns the value of that character, as an unsigned
char converted to int. (On a typical system, this will be a value in
the range 0..255.) If it failed, it returns the value EOF, which is
distinct from any valid character value.

A system will typically have some mechanism for the user to cause an
end-of-file condition when a program is reading from an interactive
device such as a keyboard. Under Unix, this is typically indicated by
typing control-D. Under MS-DOS, it's usually control-Z. Your program
won't see the control-D (4) or control-Z (26) value; it will instead
see the value EOF.

A disk file may or may not have some marker at the end of it to
indicate the end of the file. Under MS-DOS, a text file might have a
control-Z character at the end; under Unix, the system simply keeps
track of how big the file is.

--
Keith Thompson (The_Other_Keith) kst- <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.
 
Reply With Quote
 
Chuck F.
Guest
Posts: n/a
 
      01-04-2006
Gladiator wrote:
>
> When I am trying to execute a program from "The C Programming
> Language" by Dennis Ritchie, I tried to run the following
> program. I am using Dev++ as a compiler software. The Program
> is presented below. >
>
> #include <stdio.h>
> main()
> {
> long nc;
>
> nc = 0;
> while(getchar() != EOF)
> ++nc;
> printf("%1d\n",nc);
> }
>
> Whatever I am typing, It is displayed in the black window. I am
> not able to reach the EOF as specified in the While statement
> even after giving a considerable inputs. I have 2 questions.
>
> 1st is I simply cannot understand the logic of the program even
> after going through it. Whatever the input we are typing in is
> appearing in the window. Is there any where the data is being
> stored. I would be thankful if someone could explain the use of
> the program in layman's language.


Understanding the program is greatly enhanced by proper
indentation. Compare the version below:

#include <stdio.h>
main()
{
long nc;

nc = 0;
while(getchar() != EOF)
++nc;
printf("%1d\n",nc);
}

and I have omitted complaining about the lack of "return 0" or
accurate declaration of main.

>
> 2nd question is, we are using the EOF to compare it with a
> value. Is it necessary to specify the EOF value before we use it
> in a comparison?. One way what i could think is the EOF value
> may be the maximum value that the variable can hold ( In this
> "Long"). But I am not sure about it.


EOF is a macro, which you loaded when you #included <stdio.h>. You
don't care what the value is, just that it is unique, and different
from any possible char value.

Notice that the return from getchar() is only tested, never stored
(in this program). It is of type int, which allows it to take on
values outside the range of char, such as EOF.


--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
 
Reply With Quote
 
yogeshmk
Guest
Posts: n/a
 
      01-04-2006
wow!
I must say that this is an eye opener for me. All this time i was under
the impression that EOF is a special character. Coming from a Cobol
background sentences like OPEN <FILE> AT END.. verbs, and because of
MPE/iX intrinsics like FWRITEDIR which 'writes' EOF marker at the end
of last record in file, I was 'convinced' that EOF is a character like
CR/LF which is present in the file. I somehow never thought that it
could be a condition not a character.

Thanx for the nice explanation.
~yogesh

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-04-2006
"Chuck F. " <> writes:
[...]
> EOF is a macro, which you loaded when you #included <stdio.h>. You
> don't care what the value is, just that it is unique, and different
> from any possible char value.
>
> Notice that the return from getchar() is only tested, never stored
> (in this program). It is of type int, which allows it to take on
> values outside the range of char, such as EOF.


A quibble: EOF commonly is in the range of char on systems where plain
char is signed. getchar() returns the next character as an unsigned
char converted to an int; EOF, since it's negative, is guaranteed to
be outside the range of unsigned char.

--
Keith Thompson (The_Other_Keith) kst- <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.
 
Reply With Quote
 
osmium
Guest
Posts: n/a
 
      01-04-2006

"Keith Thompson" <kst-> wrote in message
news:...
> "Chuck F. " <> writes:
> [...]
>> EOF is a macro, which you loaded when you #included <stdio.h>. You
>> don't care what the value is, just that it is unique, and different
>> from any possible char value.
>>
>> Notice that the return from getchar() is only tested, never stored
>> (in this program). It is of type int, which allows it to take on
>> values outside the range of char, such as EOF.

>
> A quibble: EOF commonly is in the range of char on systems where plain
> char is signed. getchar() returns the next character as an unsigned
> char converted to an int; EOF, since it's negative, is guaranteed to
> be outside the range of unsigned char.
>
> --
> Keith Thompson (The_Other_Keith) kst-
> <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.



 
Reply With Quote
 
osmium
Guest
Posts: n/a
 
      01-04-2006
"Keith Thompson" writes:

> "Chuck F. " <> writes:
> [...]
>> EOF is a macro, which you loaded when you #included <stdio.h>. You
>> don't care what the value is, just that it is unique, and different
>> from any possible char value.
>>
>> Notice that the return from getchar() is only tested, never stored
>> (in this program). It is of type int, which allows it to take on
>> values outside the range of char, such as EOF.

>
> A quibble: EOF commonly is in the range of char on systems where plain
> char is signed. getchar() returns the next character as an unsigned
> char converted to an int; EOF, since it's negative, is guaranteed to
> be outside the range of unsigned char.


And what exactly, is the quibble? He said it was an int. Are you saying he
was wrong? Or what? Do you mean to suggest that it can, in some
circumstances, be detected as a char? I don't think that what was going
through the mind of a compiler writer as he wrote some code is terribly
interesting.


 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      01-04-2006
osmium wrote:

> "Keith Thompson" writes:
>
>> "Chuck F. " <> writes:
>> [...]
>>> EOF is a macro, which you loaded when you #included <stdio.h>. You
>>> don't care what the value is, just that it is unique, and different
>>> from any possible char value.
>>>
>>> Notice that the return from getchar() is only tested, never stored
>>> (in this program). It is of type int, which allows it to take on
>>> values outside the range of char, such as EOF.

>>
>> A quibble: EOF commonly is in the range of char on systems where plain
>> char is signed. getchar() returns the next character as an unsigned
>> char converted to an int; EOF, since it's negative, is guaranteed to
>> be outside the range of unsigned char.

>
> And what exactly, is the quibble? He said it was an int. Are you saying he
> was wrong?


CBF said "values outside the range of char, such as EOF".
Keith's quibble was that EOF is actually inside the range of char
on many (most?) systems, including the OP's system.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
I cannot understand why an object is created this way Shawn Java 1 09-28-2006 06:57 PM
Trying to understand character arrays. drM C Programming 20 04-06-2006 10:10 AM
Read all of this to understand how it works. then check around on otherRead all of this to understand how it works. then check around on other thelisa martin Computer Support 2 08-18-2005 06:40 AM
Don't understand wxPython event handling Robert Python 3 04-01-2004 10:46 PM
cannot understand strrev implementation tuchka C Programming 7 11-10-2003 12:41 AM



Advertisments