3

As per my understanding Ctrl+Z means EOF, isn't it? When Ctrl+Z is passed in as an input in the following program;

#include <stdio.h>

int main() 
{
   int a;
   a = getchar();

   if(a == EOF)
       printf("Program Ended\n");

   printf("Finished");
   return 0;   
}

It prints;

Program Ended
Finished

which is totally reasonable.

But when Ctrl+C is passed in as an input, Why does it outputs; Program Ended, and simply end the program? Wasn't it supposed to end the program without printing anything as per the code?

PS: I'm using gcc 6.3.0

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • 1
    Does https://en.wikipedia.org/wiki/Control-C#In_command-line_environments help? Please read https://meta.stackoverflow.com/questions/261592/how-much-research-effort-is-expected-of-stack-overflow-users. I found this literally by putting `ctrl-c` into a search engine. – Karl Knechtel Aug 03 '21 at 14:22
  • Does it still occur if you replace `printf("Program Ended\n");` by something else? Say `printf("This is a test\n");`? – StoryTeller - Unslander Monica Aug 03 '21 at 14:23
  • 3
    depends on your platform. On my linux box ctrl+d makes the standard input as EOF. – hetepeperfan Aug 03 '21 at 14:23
  • 1
    it's the signal sent from the terminal and has nothing to do with the compiler – phuclv Aug 03 '21 at 14:25
  • Does this answer your question? [What exactly is the effect of Ctrl-C on C++ Win32 console applications?](https://stackoverflow.com/questions/914613/what-exactly-is-the-effect-of-ctrl-c-on-c-win32-console-applications) – phuclv Aug 03 '21 at 14:26
  • `Ctrl+Z` (`Ctrl+D` in Uni*x land) is caught by the Operating System and sent to your executable as a signal that there is no more data (as `EOF`). `Ctrl+C` is caught by the OS... and sent to your executable as a signal to terminate. Your executable does not ever see `Ctrl+Z` (`0x1A`) or `Ctrl+D` (`0x04`) or `Ctrl+C` (`0x03`) – pmg Aug 03 '21 at 14:26
  • other duplicates: [How to send EOF via Windows terminal](https://stackoverflow.com/q/16136400/995714), [What is EOF in the C programming language?](https://stackoverflow.com/q/1782080/995714), [Ctrl+Z behaviour in terminal](https://stackoverflow.com/q/45665230/995714) – phuclv Aug 03 '21 at 14:28
  • What operating system? – Clifford Aug 03 '21 at 15:10
  • Be careful referring to Ctrl+Z. On a Linux system that sends SIGSTOP to your process. That is a signal that cannot be caught. – Cheatah Aug 03 '21 at 18:39
  • Upen, Try again with a `'\n'` --> `printf("Finished");` --> `printf("Finished\n");` ( I suspect your buffer is not flushed on Ctrl-C) – chux - Reinstate Monica Aug 04 '21 at 01:52
  • 1
    @chux-ReinstateMonica It didn't help – A typical nerd Aug 04 '21 at 17:02

1 Answers1

3

Ctrl-C maps to the ASCII control character ETX (End-of-Text - 0x03), while Ctrl-Z maps to ASCII EOF (End-of-Text - 0x26). There is also Ctrl-D for EOT (End-of-Transmission - 0x04).

Now what a particular platform does when either of these are occur in the the stdin stream is platform specific (and not C language or GCC specific). However the macro EOF has integer value -1 (rather than ASCII value 0x03)

When your code is executed at https://onlinegdb.com/4bF8adsM4 :

  • Ctrl-C : Program terminates immediately (causes SIGINT signal to terminate process)
  • Ctrl-D : a = -1, getchar() returns immediately.
  • Ctrl-Z : a == '\n' `getchar() returns after newline (i.e. Ctrl-Z is ignored).

On Windows, (with Microsoft C in my tests):

  • Ctrl-C : a = -1, getchar() returns immediately, Program terminates after outputting "Program Ended\n" with exception "Exception thrown at 0x7747B915 (KernelBase.dll) in scratch2.exe: 0x40010005: Control-C."
  • Ctrl-D : a == EOT, getchar() returns after newline
  • Ctrl-Z : a == -1, getchar() returns after newline

In the Ctrl-C case, the exception was shown in the debugger, in normal use (from the command line, nothing is reported). When run from the command line, it actually output "Finished\n" as well. It seems that the process termination is asynchronous to the I/O and program execution and the program can continue to run for some time before being terminated. I added further text, and only some of it was output. YMMV

Either way, on Windows, Ctrl-Z on stdin does trigger an EOF signal for the stdin stream, while in Unix/Linux, it is Ctrl-D. In both cases Ctrl-C causes process termination by SIGINT, but on Windows at least, it is an asynchronous signal/exception, and the process may not terminate immediately. Also in Windows, the EOF after Ctrl-Z is buffered until after newline, whereas in Unix/Linux, it aborts the input immediately.

Note that it is possible to implement a SIGINT signal handler to trap Ctrl-C to prevent process termination by that method (or handle it more elegantly).

All the other ASCII control characters have Ctrl-key mappings, what any particular platform does with these and stdin is also platform dependent.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Control-D does't get inserted in the stream. Instead, it causes any "read line" request to return with however much text has been typed. A zero-byte return is interpreted as indicating an end-of-file condition, but if one types one or more characters before typing control-D, the effect will be to make characters before the control-D available to `getchar()` immediately, without the buffer having to contain a newline character. – supercat Aug 06 '21 at 17:52
  • @supercat Useful clarification, if a little semantic. An EOF (-1, not ASCII EOF) is returned by getchar(), so in that sense it is "as-if" it were inserted the stream, though I concede it is not technically precise. The findings were empirically determined, not by technical reference. I am not sure it matters much in this instance. – Clifford Aug 06 '21 at 18:03
  • The distinction is important if a program is receiving input from a pipe or redirected file. An operator may type control-D in the middle of a program's input, with the effect of causing one read-input request to return zero bytes without closing the stream, but a control-D received from a pipe or redirected file will simply appear as character code 4. – supercat Aug 06 '21 at 18:09
  • @supercat Yes, I will correct it when I am at a keyboard rather than a phone. In the meantime your comment will suffice. I merely meant that I'd did not make a material difference to the answer, not that there were not circumstances where it was necessary to be more precise. – Clifford Aug 06 '21 at 18:14