Does including ncurses.h in C programming also include stdio.h? - c

Question

I was studying up on ncurses.h because I am trying to learn a bit of design aspects for c, and stumbled across a statement saying that stdio.h is inside of ncurses
#include <ncurses.h> /*ncurses.h includes stdio.h*/
Is this true? If so, can someone explain to me why, and if that means I don't have to ever include it again?
Also, does this cause any issues because I am not exactly defining it in a regular sense

Answer 1

Yes, including <ncurses.h> will almost certainly include
<stdio.h>. But I advise not taking advantage of this.
The documentation for ncurses does say:
NOTES
The header file <curses.h> automatically includes the header
files <stdio.h> and <unctrl.h>.
(ncurses.h is (usually?) a symbolic link to curses.h.)
Thomas Dickey, the primary maintainer of ncurses, tells
us that this goes
back to 1994, so you're extremely unlikely to encounter an ncurses
implementation that doesn't do this.
The X/Open Curses standard, which ncurses supports, says (emphasis added):
The inclusion of <curses.h> may make visible all symbols from
the headers <stdio.h>, <term.h>, <termios.h>, and <wchar.h>.
Furthermore, some functions defined in <ncurses.h> and/or
<curses.h> take arguments of type FILE, which is defined in
<stdio.h>. (It's conceivable that something could use the FILE
type without including <stdio.h>, but that would be contrived and
silly, and the possibility is not worth worrying about.)
So #include <ncurses.h> is practically guaranteed to include
<stdio.h>.
Having said all that, I advise against taking advantage of this
guarantee. If your C source file depends on things declared in
<stdio.h>, as a matter of style you should have an explicit
#include <stdio.h>, even though it's strictly redundant.
More generally, a C source file should have a #include directive
for any header that it depends on. This is a matter of style and
maintainability, not an absolute requirement. See, for example,
this question. The C standard guarantees that including <stdio.h> more than once
will not cause problems.

Answer 2

In general, even if one header includes another as part of its implementation, you should always trust the C standard and the documentation of whatever API you're using. If it says that a certain header file is the one that contains a certain item, or it says that in order to access a certain item, include this header, you should follow that.
It's not harmful to include the same file multiple times if it has include guards (i.e. #pragma once or #ifndef _HEADER_NAME ... #endif)
You're technically relying on an implementation detail if you omit an include that the C standard (or API documentation) says is the correct file to include for a certain declaration or definition. That means that the next version of your compiler or library could very well remove that convenient nested include that makes your program a couple of lines shorter.

Answer 3

It does indeed include stdio.h, and yes this does mean that you don't need to include stdio.h again.
This works because the compiler will insert the contents of the #include'd header files at the point in your code that the #include directive was placed. This means that not only was ncurses.h included in your code at the location you specified, but stdio.h was already included in that file at the appropriate location prior to it being placed into your code.
Subsequent includes of stdio.h will have no effect on your program due to the use of include guards.
If you're using anything from stdio.h in your own code I would consider it good practice to add the #include <stdio.h> directive to your own source files. My reasoning is that it communicates directly to the next developer reading your code that stdio functionality is used here without relying on implicit information.

Answer 4

ncurses' curses.h includes <stdio.h> because a few of the (X/Open Curses) standard functions which curses.h declares use FILE. The C standard refers to FILE as an "object type", which some might read literally as requiring a typedef. However there have been implementations where FILE is a symbol defined with #define, e.g.,
#define FILE struct _iobuf
(quoting from more than one BSD: 4.3BSD, SunOS 4, Ultrix). Without delving into its history, I'd assume the change to make it a typedef came from the AT&T code since it shows up in the SVr4 implementations.
For that reason (as well as it being the simplest way to guarantee that FILE is declared properly), curses.h will include stdio.h.
Now... there are a few other header files which you might encounter which require another header file to be included, to make them useful. One longstanding example is for the stat function, i.e.,
#include <sys/types.h>
#include <sys/stat.h>
but in the relevant (system-specific) documentation, both headers are shown in the manual page summary. The POSIX documentation for stat does not point that out, but uses it in the examples. Some newer implementations include (or provide in some roundabout way) the definitions from <sys/types.h> needed in <sys/stat.h>, but in writing portable code, that has not been something to rely upon.
curses was never documented in that way, e.g., you're unlikely to find manual pages showing
#include <stdio.h>
#include <curses.h>
because the original 4BSD curses included <stdio.h>. Interestingly enough, 4.2BSD curses header did not use any definition from stdio.h. It also included sgtty.h (analogous to termios.h), but used those definitions in the header file. Perhaps the original developer thought that including stdio.h was a good idea. In any case, in later versions of curses, it did use FILE, and since the precedent of including stdio.h. from curses.h was well established, no one considered splitting things up as done with <sys/types.h> and <sys/stat.h>.
ncurses' documentation has mentioned the header files which curses.h includes, in a NOTES section:
The header file <curses.h> automatically includes the header files
<stdio.h> and <unctrl.h>.
That note dates back to ncurses 1.8.7 in 1994, making it rather unlikely that you will encounter a version of ncurses for which the statement is untrue.
X/Open Curses has something similar to say:
The inclusion of <curses.h> may make visible all symbols from the headers <stdio.h>, <term.h>, <termios.h> and <wchar.h>.
HPUX curses, for instance, includes <term.h> from <curses.h> to declare setupterm in curses.h, but ncurses (and Solaris curses) do not. AIX curses includes <term.h> and <termios.h>. Again, ncurses (and Solaris curses) do not. X/Open Curses says "may make visible" because including a header file does not necessarily make all symbols in it visible (there are ifdef's to consider).
However, these functions in any X/Open Curses (i.e., anything more current than 1990) use FILE, making <stdio.h> needed for <curses.h>:
getwin (SVr4)
newterm (SVr2)
putwin (SVr4)
Now... including <stdio.h> before <curses.h> probably will not make any difference (aside from adding clutter to your program). It's possible (but unlikely) that there could be some symbol redefined in <curses.h> which alters the behavior of the standard features in <stdio.h>. Since any implementation of stdio.h which you are likely to encounter has include-guards (a feature from the 1990s—not seen in SunOS 4's 1994 headers) including <stdio.h> after <curses.h> would also be unlikely to change the behavior of your program (again, clutter being the only result).
Include-guards have been the preferred style for system headers since the 1990s. I have a script (called Include) which I use for test-compiling headers which I wrote in 1998, to check that a given header includes the necessary headers (such as in this case) to provide all of the necessary typedefs and symbols used in the header file.