Do stdio file descriptors (stdin, stdout, stderr) get opened, simply from #include'ing <stdio.h>?

They are opened even if you do NOT include stdio.h. They are the standard streams of a program and are opened already when it's run.

A program needs some initialization before it's actually executed. This includes loading symbol tables, assigning memory, initializing static data and linking dynamic libraries and so on. The standard streams are opened at this point. Then the control goes to the main() function in your program and it starts executing.

For the 2nd question, the standard IO doesn't bloat your program because your program is almost always linked against the standard C library libc, and is often link dynamically (so it doesn't add to the size of your executable).

Yes it's fine if you don't use them. You can do it all well using only with stuffs like snprintf(), but the standard streams will still be opened. Using them or not doesn't matter.

^{Thanks Paul Ogilvie}

No, those files are not "opened" by including a header file. Including a header file happens a compile-time, the opening of the file at run-time.

All programs needs some initialization done before the main function is called. This is usually done by the program not really starting at the main function, but at some other piece of code, a piece that is supplied by the compiler. This pre-main code will do some general initialization needed for your program to be able to function properly, and among that initialization is the setup of the standard files.

How those files are created, and if they reference some lower-level file-handle (like e.g. the FILENO_STDOUT file descriptor for stdout on a POSIX system) is largely irrelevant. All you need to know is that e.g. stdout will exist when execution starts in the main function.

Including the stdio header or not is unrelated to whether these file descriptors will open or not.

These are standard streams that are opened from the Operating System (or the shell) for your program, not by the program for itself.

There is a lot that goes on behind the scenes to handle files, streams, and formatted output. Yes, including <stdio.h> and using routines from it incurs a significant amount of overhead. But the standard streams are part of an entire system of things operating together. The C library provides routines for using the streams, the operating system provides calls for accessing the file system, and command-line shells or other processes provide already-open streams when your process starts, and so on.

For normal processes, you can ignore this. For executing commands (directly typed by you or in shell scripts), it is a minor cost of all the things that happen to make commands work. Additionally, your executable may be linked to the standard library or libraries dynamically rather than statically. This means the library is not built into your executable. It is available when your program runs, but it is shared with other processes in the system, and your program’s connection to it incurs little additional overhead.

If you are working on some special process or other special software, such as a network daemon or a device driver, there are ways to avoid linking in the standard C library or parts of it. However, these are all platform specific, and you would have to provide more information (likely in other Stack Overflow questions) about exactly what you are trying to do and which platforms (hardware, operating system, developer tools) you are using.

Some of the tools for developing special software include stripped-down libraries that provide simple routines without a lot of overhead.

Additionally, C allows declaring things without defining them. The <stdio.h> header declares various buffers and other data structures that it needs, but it is possible that, if you do not use streams or other features that needs these structures, the linker will not import from the library the modules that define them, and so they will not become a part of your executable. The details of this depend on the C implementation.

I'm a little annoyed about including stdio.h -- wouldn't that bloat the binary with unnecessary file descriptors and other code?

No. Linking the C runtime adds to your code, but without it, you won't be able to do much. This runtime contains startup code which will make sure the standard streams are available. On many systems, a newly started process already gets the respective opened files from the start, possibly inherited by the parent process.

Actually, these streams are opened even before your executable gets loaded. This is what's typically happening:

• Some shell parses a command that tells it to execute your program. This command may include redirections of stdin, stdout, and `stderr.

• The shell calls fork() to create a new process. That new process is still running shell code.

• The shell code within the new process opens input/output streams as prescribed by the redirections it has parsed. If you said 2>/dev/null, it will open /dev/null as file descriptor 2.

• The forked shell code calls exec(), to yield control to your code.

• When your code writes to stdout, it simply writes to the already open file descriptor 2.

You see, the interpretation of the file descriptors 0, 1, and 2 is simply a convention for passing open file descriptors to a process. You can instruct your shell to open more file descriptors 5>myCoolStream, or to close existing file descriptors. If that is, what your process expects, that's fine. If your process expects something else, well, that's your problem.

As such, whether you include <stdio.h> or not has no effect apart from providing the usual function prototypes and type definitions for printf() etc. The streams themselves are not influenced by this at all.