C Language, Unexpected behavior reading EOF in midstream

Nolan Eg
#1 / 17

Unexpected behavior reading EOF in midstream

While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
that has puzzled me. It seems as if EOF is not detected unless it is
at the beginning of a character sequence. To make sure it wasn't the
program as it was, I wrote this short thing and encountered the same
problem:

#include <stdio.h>

void main() {

int charRead = 1;

while (charRead != EOF) {
charRead = getchar();
printf("%d\n", charRead );
}
return;

Quote:

}

Pressing 'a' and 'enter' prints out 97 and then 10.
Pressing Ctrl-Z and 'enter'gets a -1 printed and terminates the
program.
Pressing 'a' and then Ctrl-Z and then 'enter' gives 97 and then it
waits for more input.

Why doesn't it detect the EOF after the character? I would have
expected it to print 97 and then -1 and terminate the program, but it
seems as if the Ctrl-Z is instead clearing the input buffer? Any
insight into this behavior would be much appreciated!

I'm using WinXP SP1, Visual Studio 6 SP3.

Regards,
Nolan Egly

All mail to my Yahoo! account is deleted without being read. Please
reply here.
--

Sun, 17 Jul 2005 10:55:49 GMT

Brian Ingli
#2 / 17

Unexpected behavior reading EOF in midstream

Quote:

>While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
>that has puzzled me. It seems as if EOF is not detected unless it is
>at the beginning of a character sequence. To make sure it wasn't the
>program as it was, I wrote this short thing and encountered the same
>problem:

>#include <stdio.h>

>void main() {

> int charRead = 1;

> while (charRead != EOF) {
> charRead = getchar();
> printf("%d\n", charRead );
> }
> return;
>}

>Pressing 'a' and 'enter' prints out 97 and then 10.
>Pressing Ctrl-Z and 'enter'gets a -1 printed and terminates the
>program.
>Pressing 'a' and then Ctrl-Z and then 'enter' gives 97 and then it
>waits for more input.

>Why doesn't it detect the EOF after the character? I would have
>expected it to print 97 and then -1 and terminate the program, but it
>seems as if the Ctrl-Z is instead clearing the input buffer? Any
>insight into this behavior would be much appreciated!

>I'm using WinXP SP1, Visual Studio 6 SP3.

Stop writing Pascal -- write idiomatic C.
C puts the I/O function call and error/eof test in the while
condition:

while ((charRead = getchar()) != EOF)

Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--

fake address use address above to reply

--

Tue, 19 Jul 2005 10:25:24 GMT

Bruce G. Stewar
#3 / 17

Unexpected behavior reading EOF in midstream

Quote:

>While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
>that has puzzled me. It seems as if EOF is not detected unless it is
>at the beginning of a character sequence. To make sure it wasn't the
>program as it was, I wrote this short thing and encountered the same
>problem:

>#include <stdio.h>

>void main() {

> int charRead = 1;

> while (charRead != EOF) {
> charRead = getchar();
> printf("%d\n", charRead );
> }
> return;
>}

>Pressing 'a' and 'enter' prints out 97 and then 10.
>Pressing Ctrl-Z and 'enter'gets a -1 printed and terminates the
>program.
>Pressing 'a' and then Ctrl-Z and then 'enter' gives 97 and then it
>waits for more input.

>Why doesn't it detect the EOF after the character? I would have
>expected it to print 97 and then -1 and terminate the program, but it
>seems as if the Ctrl-Z is instead clearing the input buffer? Any
>insight into this behavior would be much appreciated!

The behavior of "end-of-file" from a keyboard is very much
operating-system dependent. Standard c doesn't specify how (or even
if) particular devices might create an eof condition. Getchar() will
return -1 if it detects such a condition. From your experiments, it
seems your operating system and library combination consider it to be
Ctrl-Z at the beginning of a line.

That may not be what you want, but Standard C doesn't forbid it to
work that way.
--

Tue, 19 Jul 2005 10:25:26 GMT

CBFalcone
#4 / 17

Unexpected behavior reading EOF in midstream

Quote:

> While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
> that has puzzled me. It seems as if EOF is not detected unless it is
> at the beginning of a character sequence. To make sure it wasn't the
> program as it was, I wrote this short thing and encountered the same
> problem:

> #include <stdio.h>

> void main() {

> int charRead = 1;

> while (charRead != EOF) {
> charRead = getchar();
> printf("%d\n", charRead );
> }
> return;
> }

> Pressing 'a' and 'enter' prints out 97 and then 10.
> Pressing Ctrl-Z and 'enter'gets a -1 printed and terminates the
> program.
> Pressing 'a' and then Ctrl-Z and then 'enter' gives 97 and then it
> waits for more input.

> Why doesn't it detect the EOF after the character? I would have

Because the implementors have decided that that is the way it
should work. Doing so allows entry of a ^Z as a character in the
middle of a line, which may be useful.

--

Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
--

Tue, 19 Jul 2005 10:25:29 GMT

Jack Klei
#5 / 17

Unexpected behavior reading EOF in midstream

comp.lang.c.moderated:

Quote:

> While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
> that has puzzled me. It seems as if EOF is not detected unless it is
> at the beginning of a character sequence. To make sure it wasn't the
> program as it was, I wrote this short thing and encountered the same
> problem:

> #include <stdio.h>

> void main() {

> int charRead = 1;

> while (charRead != EOF) {
> charRead = getchar();
> printf("%d\n", charRead );
> }
> return;
> }

> Pressing 'a' and 'enter' prints out 97 and then 10.
> Pressing Ctrl-Z and 'enter'gets a -1 printed and terminates the
> program.
> Pressing 'a' and then Ctrl-Z and then 'enter' gives 97 and then it
> waits for more input.

> Why doesn't it detect the EOF after the character? I would have
> expected it to print 97 and then -1 and terminate the program, but it
> seems as if the Ctrl-Z is instead clearing the input buffer? Any
> insight into this behavior would be much appreciated!

> I'm using WinXP SP1, Visual Studio 6 SP3.

> Regards,
> Nolan Egly

> All mail to my Yahoo! account is deleted without being read. Please
> reply here.

This is actually not a C language or library issue so much as one
about the Windows console driver. The C library does not actually
access your keyboard, or know that a keyboard exists. Nor does it
know that Ctrl-Z happens to be the keyboard combination that signals
an end of file condition in MS-DOS/Windows environments, because the
usual combination is different on various other operating systems.

When a program built by your implementation (compiler and assorted
tools) for your platform is invoked, start-up code provided by the
compiler performs a number of platform specific operations to create
the standard C abstract machine environment, then it calls your main()
function.

Some of those start up functions connect system specific byte streams
into C FILE * streams, and associate them with stdin, stdout, and
stderr.

When your program calls getchar(), ultimately the C library function
asks a Windows operating system specific function for characters.
That function returns either characters or some indication of an end
of file condition. Exactly what constitutes an end of file condition
is up to Windows and its console driver, not your C code or the
getchar() function. If the Windows console driver ignores Ctrl-Z
characters unless they occur in a certain position in a sequence and
does not inform getchar() of an end of file condition, there is
nothing that getchar() can do about it.

Note that Ctrl-Z is not necessary for recognizing end of file in
general, just from the console. Create a small single line text file
and run your program from a command line prompt with its input coming
from that file:

myprog < file.txt

Note that it quite handily work just fine and indicate that it has
found the end of file once it has read all the characters. No Ctrl-Z
involved, just the Windows disk file driver telling getchar() that the
end of file has been reached.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
--

Tue, 19 Jul 2005 10:25:33 GMT

Douglas A. Gwy
#6 / 17

Unexpected behavior reading EOF in midstream

Quote:

> Pressing 'a' and then Ctrl-Z and then 'enter' gives 97 and then it
> waits for more input.
> Why doesn't it detect the EOF after the character?

Apparently WinXP/VS6.0SP3 is to some extent emulating the
Unix system behavior. There is a long answer and a short
answer; the short one is that ^Z (or ^D on Unix) is taken
as EOF only if it is the first character after a newline,
i.e. at the beginning of a (new) line. Elsewhere, it
causes the partially assembled line to be passed to the
program without waiting for a newline. The long answer
is that it acts as a delimiter, and a record of 0 length
is interpreted as end of file.
--

Tue, 19 Jul 2005 10:25:36 GMT

Herbert Rosen
#7 / 17

Unexpected behavior reading EOF in midstream

Quote:

> While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
> that has puzzled me. It seems as if EOF is not detected unless it is
> at the beginning of a character sequence. To make sure it wasn't the
> program as it was, I wrote this short thing and encountered the same
> problem:

The problem is your program - it is wrong!

Quote:

> #include <stdio.h>

> void main() {

> int charRead = 1;

> while (charRead != EOF) {

you stars up ant tests nothing relevant

Quote:

> charRead = getchar();

You reads a char - but it may be even EOF. That is because either the
stram has another char, then you gets it or there is nothing more to
read - then you gets EOF.

Quote:

> printf("%d\n", charRead );

Now you does nothing that print the EOF

Quote:

> }
> return;
> }

simple to understund, but more compliated to write:

int c; /* must be int, because getchar returns int, not char */

c = getchar(); /* read the first char in */
while (c != EOF) {
printf("%c\n", c); /* put the char */
c = getchar(); /* read the next char */

Quote:

}

or a bit more easy to write:

int c;

while ((c = getchar()) != EOF)
printf("%c\n", c);

When you doesn't test the char you've last readed you'll do something
with EOF instead of a char.

--
Tschau/Bye

Herbert Rosenau
http://www.pc-rosenau.de eComStation Reseller in Germany
eCS 1.1 ist da!
--

Tue, 19 Jul 2005 10:25:47 GMT

Hans-Bernhard Broeke
#8 / 17

Unexpected behavior reading EOF in midstream

Quote:

> While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
> that has puzzled me. It seems as if EOF is not detected unless it is
> at the beginning of a character sequence.

Strange terminology. What you call a "character sequence" is actually
a line of input text.

Quote:

> Why doesn't it detect the EOF after the character?

That's not in the control of your program at all. It's up to the
execution platform to define what you have to do to generate
end-of-file for a console input. Yours is of the DOS-ish type, and
yes, those may only recognize "Ctrl-Z at the beginning of a line" as
signalling end-of-file.

In summary: you usually can't "type" EOF --- you type something to
tell the operating system to generate an end-of-file condition.

--

Even if all the snow were burnt, ashes would remain.
--

Tue, 19 Jul 2005 10:25:50 GMT

Keith Thompso
#9 / 17

Unexpected behavior reading EOF in midstream

Quote:

> While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
> that has puzzled me. It seems as if EOF is not detected unless it is
> at the beginning of a character sequence.

You didn't enter "EOF"; you entered control-Z.

End-of-file is logically a condition, not a character. It's
represented in your program by getchar() returning the value EOF
(which happens to be -1 in your implementation; in any case it's not a
valid unsigned character value).

The manner in which an end-of-file condition is triggered varies from
one system to another, and from one file to another. If you were
reading from a disk file, it would probably be triggered simply by
reaching the end of the file. It appears that on your system, when
reading from the keyboard, an end-of-file condition is triggered by
typing control-Z immediately after typing <enter>. If you type
control-Z in the middle of a line, it appears that it's ignored --
which is a perfectly legitimate thing for your implementation to do.

--

San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
--

Tue, 19 Jul 2005 10:25:52 GMT

Phil Carmod
#10 / 17

Unexpected behavior reading EOF in midstream

Quote:

> While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
> that has puzzled me. It seems as if EOF is not detected unless it is
> at the beginning of a character sequence. To make sure it wasn't the
> program as it was, I wrote this short thing and encountered the same
> problem:

> #include <stdio.h>

> void main() {

> int charRead = 1;

> while (charRead != EOF) {
> charRead = getchar();
> printf("%d\n", charRead );
> }
> return;
> }

> Pressing 'a' and 'enter' prints out 97 and then 10.
> Pressing Ctrl-Z and 'enter'gets a -1 printed and terminates the
> program.
> Pressing 'a' and then Ctrl-Z and then 'enter' gives 97 and then it
> waits for more input.

> Why doesn't it detect the EOF after the character? I would have
> expected it to print 97 and then -1 and terminate the program, but it
> seems as if the Ctrl-Z is instead clearing the input buffer? Any
> insight into this behavior would be much appreciated!

It isn't detecting the 'EOF' because windows isn't sending it one.
It's the console that is dropping the ^Z that isn't at the beginning of
the line. There may be some ioctl that you can use to change that
behaviour though.

Phil
--

Tue, 19 Jul 2005 10:25:53 GMT

Dan P
#11 / 17

Unexpected behavior reading EOF in midstream

Quote:

>The behavior of "end-of-file" from a keyboard is very much
>operating-system dependent. Standard c doesn't specify how (or even
>if) particular devices might create an eof condition. Getchar() will
>return -1 if it detects such a condition. ^^^^

^^^^^^^^^
Does the C standard say so?

Dan
--
Dan Pop
DESY Zeuthen, RZ group

--

Wed, 20 Jul 2005 12:10:04 GMT

Barry Schwar
#12 / 17

Unexpected behavior reading EOF in midstream

Quote:

>While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
>that has puzzled me. It seems as if EOF is not detected unless it is
>at the beginning of a character sequence. To make sure it wasn't the
>program as it was, I wrote this short thing and encountered the same
>problem:

>#include <stdio.h>

>void main() {

> int charRead = 1;

> while (charRead != EOF) {
> charRead = getchar();
> printf("%d\n", charRead );
> }
> return;
>}

>Pressing 'a' and 'enter' prints out 97 and then 10.
>Pressing Ctrl-Z and 'enter'gets a -1 printed and terminates the
>program.
>Pressing 'a' and then Ctrl-Z and then 'enter' gives 97 and then it
>waits for more input.

>Why doesn't it detect the EOF after the character? I would have
>expected it to print 97 and then -1 and terminate the program, but it
>seems as if the Ctrl-Z is instead clearing the input buffer? Any
>insight into this behavior would be much appreciated!

>I'm using WinXP SP1, Visual Studio 6 SP3.

I use VC 6 on Win 98 but I don't remember the SP level. It worked
differently than you describe:

a+enter produces 97, 10, and a wait for more input (same as yours)
Ctrl-z produces no output and program termination
a+Ctrl-z produces -1 and program termination

It could be SP level but I expect it is more likely OS differences.

<<Remove the del for email>>
--

Fri, 22 Jul 2005 09:28:33 GMT

Barry Schwar
#13 / 17

Unexpected behavior reading EOF in midstream

Quote:

>> While working on Excerise 1-12 in K&R 2nd ed. I ran into a problem
>> that has puzzled me. It seems as if EOF is not detected unless it is
>> at the beginning of a character sequence. To make sure it wasn't the
>> program as it was, I wrote this short thing and encountered the same
>> problem:

>The problem is your program - it is wrong!

>> #include <stdio.h>

>> void main() {

>> int charRead = 1;

>> while (charRead != EOF) {

>you stars up ant tests nothing relevant

Since charRead is 1 and EOF is guaranteed not to be one, this
evaluates to true on the first iteration of the loop. This is exactly
what he wants. EOF has not yet occurred and he wants to execute the
loop.

Quote:

>> charRead = getchar();

>You reads a char - but it may be even EOF. That is because either the
>stram has another char, then you gets it or there is nothing more to
>read - then you gets EOF.

>> printf("%d\n", charRead );

>Now you does nothing that print the EOF

Since EOF is a numeric value (that is why getchar returns int), there
is no problem printing it with %d.

- Show quoted text -

Quote:

>> }
>> return;
>> }

>simple to understund, but more compliated to write:

>int c; /* must be int, because getchar returns int, not char */

>c = getchar(); /* read the first char in */
>while (c != EOF) {
> printf("%c\n", c); /* put the char */
> c = getchar(); /* read the next char */
>}

>or a bit more easy to write:

>int c;

>while ((c = getchar()) != EOF)
> printf("%c\n", c);

>When you doesn't test the char you've last readed you'll do something
>with EOF instead of a char.

Yes, he will print out its numeric value. So what?

Quote:

>--
>Tschau/Bye

>Herbert Rosenau
>http://www.pc-rosenau.de eComStation Reseller in Germany
>eCS 1.1 ist da!

<<Remove the del for email>>
--

Fri, 22 Jul 2005 09:28:41 GMT

Kenneth Brod
#14 / 17

Unexpected behavior reading EOF in midstream

[...]

Quote:

> int charRead = 1;

> while (charRead != EOF) {
> charRead = getchar();
> printf("%d\n", charRead );
> }
> return;
> }

> Pressing 'a' and 'enter' prints out 97 and then 10.
> Pressing Ctrl-Z and 'enter'gets a -1 printed and terminates the
> program.
> Pressing 'a' and then Ctrl-Z and then 'enter' gives 97 and then it
> waits for more input.

> Why doesn't it detect the EOF after the character? I would have
> expected it to print 97 and then -1 and terminate the program, but it
> seems as if the Ctrl-Z is instead clearing the input buffer? Any
> insight into this behavior would be much appreciated!

> I'm using WinXP SP1, Visual Studio 6 SP3.

[...]

This is an O/S issue, not a C issue.

Under Unix, typing the EOF character in the middle of a line (in
line mode, as opposed to raw mode) does not signal EOF. It merely
signals end-of-line. Only typing the EOF character at the start
of a line signals EOF from the tty.

(Actually, it's not "the EOF character", but rather "the character
that is used to signal EOF when received from a tty device".)

I can only assume that Windows chose to duplicate this behavior.

--
Kenneth Brody http://www.fileproplus.com http://www.hvcomputer.com
filePro: Celebrating 25 years of providing powerful cross-platform
application development tools
--

Fri, 22 Jul 2005 09:28:54 GMT

Bruce G. Stewar
#15 / 17

Unexpected behavior reading EOF in midstream

Quote:

>>The behavior of "end-of-file" from a keyboard is very much
>>operating-system dependent. Standard c doesn't specify how (or even
>>if) particular devices might create an eof condition. Getchar() will
>>return -1 if it detects such a condition. ^^^^
> ^^^^^^^^^
>Does the C standard say so?

>Dan

Foolish me. I misspelled EOF in my message. ...will return EOF if...
--

Fri, 22 Jul 2005 09:28:52 GMT