stdin(3)

๐Ÿ’– stdin(3) โ€” the standard I/O streams, aka your fave three besties

okay so bestie, welcome to stdin(3), a page from the Library Functions Manual. this is the one that explains the three streams every UNIX program gets handed at birth and honestly? they're iconic. let's get into it ๐Ÿ’…


โœจ NAME โœจ

stdin, stdout, stderr โ€” standard I/O streams ๐ŸŽ€

๐Ÿ“š LIBRARY ๐Ÿ“š

Standard C library (libc, -lc). yes ma'am, the classic.

๐Ÿฆ‹ SYNOPSIS ๐Ÿฆ‹

#include <stdio.h>

extern FILE  *stdin;
extern FILE  *stdout;
extern FILE  *stderr;

look at them. three little pointers to FILE, just vibing. ๐ŸŒธ

๐Ÿ’œ DESCRIPTION ๐Ÿ’œ

so like, under normal circumstances, every single UNIX program has three streams opened for it the second it starts up:

  • one for input ๐Ÿ“
  • one for output โœจ
  • one for printing diagnostic or error messages ๐Ÿšจ

these are typically attached to the user's terminal (peep tty(4)) but bestie, they might instead refer to files or other devices, depending on what the parent process chose to set up. (also check the "Redirections" section of sh(1) โ€” iykyk.)

the input stream is referred to as "standard input", the output stream is referred to as "standard output", and the error stream is referred to as "standard error". those get abbreviated into the actual symbols we use to refer to these files, namely stdin, stdout, and stderr. periodt.

each of these symbols is a stdio(3) macro of type pointer to FILE, and you can use them with functions like fprintf(3) or fread(3). slay.

since FILEs are literally just a buffering wrapper around UNIX file descriptors, the same underlying files may also be accessed using the raw UNIX file interface, that is, the functions like read(2) and lseek(2). two doors, same room, no cap.

on program startup, the integer file descriptors associated with the streams stdin, stdout, and stderr are 0, 1, and 2, respectively. the preprocessor symbols STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO are defined with these values in <unistd.h>. (and fun fact: applying freopen(3) to one of these streams can change the file descriptor number associated with the stream ๐Ÿ‘€)

โš ๏ธ okay important bestie โ€” note that mixing use of FILEs and raw file descriptors can produce unexpected results and should generally be avoided. (for the masochistic among you: POSIX.1, section 8.2.3, describes in detail how this interaction is supposed to work. go off i guess ๐Ÿ˜ญ)

a general rule is that file descriptors are handled in the kernel, while stdio is just a library. this means, for example, that after an exec(3), the child inherits all open file descriptors, but all old streams have become inaccessible. the way that inheritance justโ€ฆ leaves the streams behind? it's giving ghosting ๐Ÿ’€

since the symbols stdin, stdout, and stderr are specified to be macros, assigning to them is nonportable. ๐Ÿšซ the standard streams can be made to refer to different files with help of the library function freopen(3), specially introduced to make it possible to reassign stdin, stdout, and stderr. and the standard streams are closed by a call to exit(3) and by normal program termination. bye babes ๐Ÿซถ


๐ŸŒˆ STANDARDS ๐ŸŒˆ

C11, POSIX.1-2008.

the standards also stipulate that these three streams shall be open at program startup. mandatory. no skipping. ๐Ÿ‘‘

๐ŸŽ€ HISTORY ๐ŸŽ€

C89, POSIX.1-2001. grandma behavior but we love her ๐Ÿ’–

๐Ÿงš NOTES ๐Ÿงš

  • the stream stderr is unbuffered. it says what it says, immediately, no filter. main character energy fr.
  • the stream stdout is line-buffered when it points to a terminal. partial lines will not appear until fflush(3) or exit(3) is called, or a newline is printed. this can produce unexpected results, especially with debugging output ๐Ÿ˜ญ (yes bestie, that's why your printf debug line vanished. it's not you, it's buffering.)
  • the buffering mode of the standard streams (or any other stream) can be changed using the setbuf(3) or setvbuf(3) call.
  • note that in case stdin is associated with a terminal, there may also be input buffering in the terminal driver, entirely unrelated to stdio buffering. (indeed, normally terminal input is line buffered in the kernel.) that kernel input handling can be modified using calls like tcsetattr(3); see also stty(1), and termios(7). layers on layers on layers ๐Ÿง…โœจ

๐Ÿ‘‘ SEE ALSO ๐Ÿ‘‘

csh(1), sh(1), open(2), fopen(3), stdio(3)


and that's the whole page bestie!! this one's from Linux man-pages 6.20, dated 2026-07-02, and it's literally the stdin(3) page itself. go forth and redirect things responsibly ๐Ÿ’…โœจ๐Ÿฆ‹

๐Ÿ“ฆ where this page comes from
  • arch rolling: man-pages 6.20-1 ยท BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
  • nixpkgs unstable: man-pages 6.20
  • ๐Ÿ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms