(I am supposing your computer has an x86-64 processor and runs Linux)
why format specifier used is %c, why not %d(or %i).
Imagine that the corresponding argument (to printf
) was 99 (an int
). If you use %c
then the letter c
(of ASCII code 99) is displayed. If you use %d
or %i
then 99
is displayed by printf
, etc...
printf
is, as you noticed, a variadic function. It is implemented using variadic primitives like va_start
and va_end
which are macros expanded to some builtin known to the compiler. How exactly arguments are passed and results are given (the calling convention) is defined (in some processor & OS specific way) in a document called ABI (application binary interface).
On some C standard library implementations, printf
(and related functions, like vfprintf
) would ultimately use putc
or something related.
Notice that standard I/O functions (those in <stdio.h>
) are likely to be provided with the help of some operating system. Read Operating Systems : Three Easy Pieces for more about OSes.
Quite often, the C standard library will use some system calls to interact with the operating system kernel. For Linux these are listed in syscalls(2), but read Advanced Linux Programming. To output some data the write(2) syscall would be used (but the C standard library is generally buffering, see setvbuf(3)).
BTW, for Linux/x86-64 both GNU glibc & musl-libc are free software implementations of the C standard library, and you can study their source code (most of it is coded in C, with a tiny bit of assembly for the system call glue).
But my problem is what's actually happening inside getchar() and printf() during the whole process, where getchar() is returning that integer, where it is getting stored ...?
The ABI defines that the result of an int
returning function goes thru register %rax
, and getchar
(like every other int
return function) works that way. See the X86-64 Linux ABI referenced here.
... and how the character we inputted is getting displayed by printf() i.e. what's happening inside printf()?
After many software layers, when the stdout
stream gets flushed (e.g. by some call to fflush(3), by a \n
newline character, or at exit(3) time, including returning from main
into crt0 code), the C standard library will use the write(2) syscall. The kernel will process it to show something (But details are horribly complex, read first the tty demystified). Actually millions of source code lines are involved (including inside the kernel - read about DRM, inside the display server such as X.Org or Wayland - also some code inside the GPU -, inside the terminal emulator). Linux is free software, so in principle you can study all of it (but that needs more than a lifetime, a typical Linux distribution has about twenty billions lines of source code). See also OSDev wiki which gives some practical information, including about native Intel grapĥics (which are the most primitive graphics today).
PS. You need to spend more than ten years understanding all the details (and I don't).