C Language: Focus on EOF

EOF refers to the terminator of a file, which is a macro definition

With the help of the GetChar and Putchar functions, you can write out without knowing other input/output knowledge
An astonishing amount of useful code. The simplest example is to copy the input one word Fu to the output, the basic idea
As follows:
Read a character
While (the character is not a file end indicator)
Output characters just read in
Read the next character
To convert the above-mentioned basic idea into a C language program:

#include <stdio.h>Main () {int  C;   = GetChar ();  while (c!= = GetChar ();}}

And understanding this code is not a difficult thing to do, but, on the contrary, it is too simple. But if you delve into it, you'll find an interesting thing, if you don't think about redirection, that is, we're typing from stdin, what information should we enter, which is considered EOF? The attentive reader may have noticed that when declaring variable C, we did not declare it as a char type, because our C must be able to accommodate so-called EOF, and imagine that the system I am using is fedora, The stdio.h file contained in glib defines EOF as 1, and it is clear that C is defined as a char type, how can he accommodate EOF?

Now I'm going to do an experiment to find out, what exactly information can end our program, assuming that my executable is test, input./test, the system waits for input, and when I enter "I am Rockics" and returns, the system outputs "I am rockics", and continues to wait for input, obviously the carriage return cannot let him quit execution.

So, I press the combination of "Ctrl + Z", the surface as if test did not execute, carefully point will find that the screen output information:

[1]+ Stopped./test

It's just stopped, but is it exit?

It is easy to verify, enter the command PS, view the current user process, I found the result:

[[Email protected] c]$ PS
PID TTY Time CMD
3365 PTS/1 00:00:00 Bash
4471 PTS/1 00:00:00 Test
4484 PTS/1 00:00:00 PS

Test is still running in the background, hehe. You must show the kill to it before you can.

Well, let's try "ctrl+d" to try, we'll first use "kill-9 4471" to kill the test and then re-execute it:

[Email protected] c]$ kill-9 4471
[1]+ has been killed./test
[Email protected] c]$./test
I am ROCKICSI am rockics

Hey, the back of the "I am rockics" is I Press "ctrl+d" output, haha, and enter the effect of almost oh, just no line break.

This time, no matter how input enter, all found that test has been waiting for user input, is not willing to quit, ah, not good.

But this time (after hitting the Enter), I press "ctrl+d" again, I found that test did not, PS, also did not find, that is, test normal completion of the task, quit.

[[Email protected] c]$ PS
PID TTY Time CMD
3365 PTS/1 00:00:00 Bash
4502 PTS/1 00:00:00 PS

That is, when the input is complete, press Enter and then "Ctrl+d" to end the test.

As for the deep analysis, of course to consider the implementation of the system, first, the input buffer is the row buffer. When you enter a string of characters from the keyboard and press ENTER, the characters inode are first sent to the input buffer for storage. Whenever the ENTER key is pressed, cin.get () detects if the input buffer has readable data. Cin.get () also checks whether there are "Ctrl + Z" or "ctrl+d" keys on the keyboard that are used as the end-of-flow flag, and is checked in two ways: blocked and non-blocking.

The blocking check method refers to whether the previous "Ctrl + Z" key combination is pressed until after the return press is pressed, and the non-blocking style refers to how the response is immediately followed by pressing "ctrl+d". If a character has been entered from the keyboard before pressing "ctrl+d", the function of "ctrl+d" is equivalent to carriage return, that is, the characters are sent to the input buffer for reading, and "ctrl+d" does not function as a stream terminator at this time. If there is no keyboard input before pressing "ctrl+d", then "ctrl+d" is the signal of the end of the stream

The Windows system generally uses the blocking check "CTRL + Z", the Unix/linux system generally adopts non-blocking check "Ctrl+d". I am using the Fedora system, so I use a non-blocking "ctrl+d" to identify the end of the stream.

bye!

C Language: Focus on EOF