-7

There has been many threads on this question for you.

However, i ran into same problem but as per unix standards this will be the exact answer when you are looking for EOF value in C programming language code.

Below is the code sniffet

#include<stdio.h>

main() {
    int c;
    while((c=getchar()) != 0x4) {
     printf("%c", c);
    }
    printf("Exited with EOF value\n");
     
}

Value of EOF as per stdio.h is -1. When you run the problem as the code of while loop is compared is in ascii . After running this problem. the output will be same as the input. But to confirm EOF value press Ctrl+D and enter. Test in Dev-C++ ide.

mcubesdev
  • 1
  • 5
    `0x4` is a character (in the form of a `int` value), **`EOF` is not a character**; `EOF` is a signal (generated by your terminal when you press the key combination Ctrl+D -- other terminals (Windows) use a different key combination for the same signal). – pmg Jun 19 '22 at 08:28
  • 3
    It is a poor idea to create a `while` loop that looks for a specific character, but that does not deal with `EOF`. Because that is the only good way you can deal with read errors. Also, the value returned is `EOF`, don't assume it's `-1` even not when reading header files. It might be different on different platforms. – Cheatah Jun 19 '22 at 08:33
  • i don't agree with the statement, as checking with specific ascii code is the standard norm in checking all the unix command line characters including the device driver codes. At least this approach gives the handle of control to the programmer – mcubesdev Jun 19 '22 at 10:16
  • 2
    @pmg: EOF is not a signal. It is not a signal in the sense of the C standard’s signals discussed in the clause on `` nor in the sense of a special message passed from the terminal software to a process. For interactive input streams, the EOF condition is created inside the C library’s stream software when an attempt to read data and the read is successful (no hardware or logical error occurs) but no data is obtained. This is entirely inside the stream software; no special signal (as in ``) is raised in the program nor sent from the terminal to the program. – Eric Postpischil Jun 19 '22 at 10:43
  • @pmg: [When Control-D is pressed, the terminal software, in its default mode, sends all pending characters to the attached program.](https://stackoverflow.com/a/21365313/298225) If there are pending characters, as when happens when you type several ordinary keys, and Control-D is pressed, those characters are sent to the program, and no EOF is generated. So pressing Control-D does not generate or signal EOF. If there are no pending characters (which happens at the start of input to a program, after a Return has sent characters, or after a Control-D has sent characters), and… – Eric Postpischil Jun 19 '22 at 10:46
  • 1
    … Control-D is pressed, then “zero characters” are sent to the program. That is, the currently pending operation requesting to read characters is completed with an indication that it received zero characters but no other error (or signal). When the stream software sees zero characters were read, it sets its internal EOF flag. That is all it is, a simple flag that is raised (a bit that is set), and whichever routine was called returns `EOF` for its return value (or possible other indication depending on the routine). – Eric Postpischil Jun 19 '22 at 10:48
  • 1
    Also note that, when this happens, the stream has not actually ended. The operating system and the terminal software have taken no note that anything special has occurred. Typed characters are still translated into data that the program can read. The program can clear the EOF flag inside the stream software by calling `clearerr(stdin)` (or other stream) and continue reading more data, because the stream is still open, connected to the terminal, and available to read data. – Eric Postpischil Jun 19 '22 at 10:55

1 Answers1

2

When you're thinking about EOF indications generated from an interactive keyboard, there are two completely different ways of thinking about it. It is easy to accidentally confuse the two.

(1) Most of the time, the operating system is performing a certain amount of "preprocessing" on keyboard input typed by the user, well before an application program — like an ordinary C program — gets ahold of it. For example: if you type a line of input terminated by the Return key, but halfway through the line you make a mistake, and hit the backspace key, and correct it, the application program won't see the mistake, or the backspace key — it will see only the characters in the corrected line.

Similarly, at least on Unix/Linux systems, the vast majority of the time, if the user presses control-D (which is indeed End Of Transmission or EOT or 0x04 in ASCII), the operating system will translate that into an end-of-file indication, and a C program will read EOF, or -1.

(2) If the program is doing something special, and wants to see every keystroke, it may place the operating system's terminal driver into "raw" or "cbreak" mode, meaning that the driver will do minimal or no processing. In that case, if the user presses control-D, the program will indeed read a value of 4, not EOF.

But, as a general rule, code like

while((c = getchar()) != 0x4) { ... }

is incorrect and will not work. On Unix, most of the time, getchar will never return 4, because control-D will have been translated into an end-of-file indication before the program ever sees it, so the program will see EOF instead.

Steve Summit
  • 45,437
  • 7
  • 70
  • 103
  • Control-D is not translated into EOF by the operating system. The EOF is generated inside the stream software inside the standard C library, and it is not directly caused by Control-D (you can press Control-D without generating EOF, by typing other ordinary characters first); it is an indirect consequence of what Control-D actually does (send pending data immediately). See my comments above and [this answer](https://stackoverflow.com/a/21365313/298225). – Eric Postpischil Jun 19 '22 at 10:50
  • In “… if the user presses control-D (which is indeed End Of Transmission or EOT or 0x04 in ASCII), the operating system will translate that into an end-of-file indication…” – Eric Postpischil Jun 19 '22 at 10:52
  • 1
    I see this as two different issues. (1) At the OS level, control-D or end-of-file is represented by `read()` returning 0 (with caveats), and code in the C library translates that into `EOF`. (Ergo it's not true that "the OS translates control-D into `EOF`".) (2) Under certain circumstances, control-D will *not* result in `read()` returning 0, after all, but will rather result in a partial line being read, not ending in LF. Case (1) is the one that everyone thinks about, and I was deliberately glossing over case (2). – Steve Summit Jun 19 '22 at 10:57
  • I suppose your point is that it's possible to think about case (2) not as the abnormal case, but as the *only* one, and that "end of file translation" falls out as a special case. – Steve Summit Jun 19 '22 at 10:58
  • 1
    But I stand by my statement (now explicitly qualified) that "the vast majority of the time, if the user presses control-D, the operating system will translate that into an end-of-file indication", i.e. `read()` returning 0. (And, yes, per your linked answer, in a C or C++ program it ends up being sort of a "temporary" EOF, variously clearable, but that doesn't seem germane to the present question.) – Steve Summit Jun 19 '22 at 11:08