81

I was wondering the difference between stdout and STDOUT_FILENO in Linux C.

After some searching work, I draw the following conclusion. Could you help me review it and correct any mistake in it? Thanks

  • stdout belongs to standard I/O stream of C language; whose type is FILE* and defined in stdio.h

  • STDOUT_FILENO, possessing an int type, is defined at unistd.h. It's a file descriptor of LINUX system. In unistd.h, it's explained as below:

The following symbolic constants shall be defined for file streams:

STDERR_FILENO
    File number of stderr; 2.
STDIN_FILENO
    File number of stdin; 0.
STDOUT_FILENO
    File number of stdout; 1.

So, in my opinion, the STDOUT_FILENO belongs system-level calling and, to some extent, like a system API. STDOUT_FILENO can be used to describe any device in system.

The stdout locates in a higher level (user level?) and actually encapsulate the details of STDOUT_FILENO. stdout has I/O buffer.

That's my understand about their difference. Any comment or correction is appreciated, thanks.

Ry-
  • 218,210
  • 55
  • 464
  • 476
Bing Lu
  • 3,232
  • 7
  • 30
  • 38

1 Answers1

106

stdout is a FILE* pointer giving the standard output stream. So obviously fprintf(stdout, "x=%d\n", x); has the same behavior as printf("x=%d\n", x);; you use stdout for <stdio.h> functions such as fprintf(), fputs() etc..

STDOUT_FILENO is an integer file descriptor (actually, the integer 1). You might use it for write syscall.

The relation between the two is STDOUT_FILENO == fileno(stdout)

(Except after you do weird things like fclose(stdout);, or perhaps some freopen after some fclose(stdin), which you should almost never do! See this, as commented by J.F.Sebastian)

You usually prefer the FILE* things, because they are buffered (so usually perform well). Sometimes, you may want to call fflush() to flush buffers.

You could use file descriptor numbers for syscalls such as write() (which is used by the stdio library), or poll(). But using syscalls is clumsy. It may give you very good efficiency (but that is hard to code), but very often the stdio library is good enough (and more portable).

(Of course you should #include <stdio.h> for the stdio functions, and #include <unistd.h> - and some other headers - for the syscalls like write. And the stdio functions are implemented with syscalls, so fprintf() may call write()).

Toby Speight
  • 27,591
  • 48
  • 66
  • 103
Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • 24
    `STDOUT_FILENO == fileno(stdout)` Wonderful, this expression helps me totally understand this issue. Thanks a lot. @Basile – Bing Lu Oct 15 '12 at 19:39
  • 2
    [`STDOUT_FILENO == fileno(stdout)`](http://stackoverflow.com/q/25516375/4279) -- is it always true? – jfs Aug 26 '14 at 22:49
  • 2
    File descriptors are also useful for redirecting streams to different places in the file descriptor table using `dup2` (for example, taking the output of a child process which makes some system call and prints to `stdout` and telling the OS to redirect that output to a text file before the system call is made) – Jake Levi Nov 24 '19 at 17:56
  • I'm confused with `STDOUT_FILENO == fileno(stdout)` _unless_ you do something weird, like [here](https://stackoverflow.com/questions/25516375/is-it-possible-that-filenostdout-1-on-a-posix-system), to me it sounds like since `STDOUT_FILENO != fileno(stdout)` is possible, wouldn't it be better to use `fileno(stdout)` in API? When do you actually need to use `STDOUT_FILENO` other than when comparing with `fileno(stdout)`? – Rich Jahn Dec 07 '21 at 21:49
  • @Rich, it's useful in programs that are not using ``. Just now, I found it useful when setting up redirection in a child process, for example, ensuring that its input and output streams were connected to the pipes I just created for it. – Toby Speight Mar 03 '23 at 15:35