Do we need to continue to include stdio.h in C files ?

[karthikbalaguru]

Hi,

The #include tells the compiler to include information
about the standard input/ouput library and this appears
in many source files.

But, why cannot C link the libraries using the linkers
automatically during linking procedure instead of having these
#includes ?

Thx in advans,
Karthik Balaguru

 

[James Kuyper]

Hi,

The #include tells the compiler to include information
about the standard input/ouput library and this appears
in many source files.

But, why cannot C link the libraries using the linkers
automatically during linking procedure instead of having these
#includes ?

The standard headers serve an entirely different purpose from the
corresponding libraries. The standard headers provide declarations and
definitions for various identifiers that your program needs to know
about in order to make use of the corresponding library, things that the
compiler needs to know about long before the link phase. The identifiers
include type names, macros, function names, and object names.

 

[Barry Schwarz]

Hi,

The #include tells the compiler to include information
about the standard input/ouput library and this appears
in many source files.

But, why cannot C link the libraries using the linkers
automatically during linking procedure instead of having these
#includes ?

#include has nothing to with linking as others have explained.

Consider the situation where a particular compiler implementer decided
to include all the details of stdio.h in the compiler so that
including stdio.h was redundant. As a user of that particular
compiler, you get out of the habit of including stdio.h.

When the next version of the standard comes out, something in stdio.h
changes. Something simple like a fourth SEEK_ macro. Under normal
conditions, this change would not require any compiler changes. Those
who include the new stdio.h would be able to use the new macro
immediately. (Yes fseek must change to deal with the new value but
that is not a compiler change.) You, however, will receive
diagnostics regarding the unknown name. You either start including
the new stdio.h (defeating the built-in feature) or wait for the
compiler writer to add the new macro to the compiler itself.

Like most other programmers, compiler writers are not usually fond of
make-work. Considering the almost non-existent return on investment,
the effort to put stdio.h into the compiler is just isn't worth it.
And why stop at stdio.h? Why not stdlib.h also? And then math.h?
etc.

 

[Bartc]

#include has nothing to with linking as others have explained.

Consider the situation where a particular compiler implementer decided
to include all the details of stdio.h in the compiler so that
including stdio.h was redundant. As a user of that particular
compiler, you get out of the habit of including stdio.h.
When the next version of the standard comes out, something in stdio.h
changes. Something simple like a fourth SEEK_ macro. Under normal
conditions, this change would not require any compiler changes. Those
who include the new stdio.h would be able to use the new macro
immediately.

The compiler could just implicitly include stdio.h, which would have (likely
already has) guards so that an extra #include <stdio.h> would not be
detrimental.

But where would the new stdio.h come from anyway?

Like most other programmers, compiler writers are not usually fond of
make-work. Considering the almost non-existent return on investment,
the effort to put stdio.h into the compiler is just isn't worth it.
And why stop at stdio.h? Why not stdlib.h also? And then math.h?
etc.

That's a good idea; there are a couple of dozen standard headers but they
don't amount to that much code. Just include the lot automatically. Or have
one super header #include <clib.h> in the same there is #include
<windows.h>.

If the standard library was spread over 200 standard headers instead of
about 20, it's easy to see the present situation is almost ridiculous.

 

[James Kuyper]

pete wrote:
....

K&R C had just one standard header, <stdio.h>.

I learned C very shortly after K&R I first came out. I remember thinking
"If almost every non-trivial C program requires #include <stdio.h>, why
don't they just make it implicit?".

 

[Stefan Ram]

I learned C very shortly after K&R I first came out. I remember thinking
"If almost every non-trivial C program requires #include <stdio.h>, why
don't they just make it implicit?".

Have you since changed your thinking?

 

[Bartc]

pete wrote:
...

I learned C very shortly after K&R I first came out. I remember thinking
"If almost every non-trivial C program requires #include <stdio.h>, why
don't they just make it implicit?".

Probably almost every trivial program too.

Is there any program, that does any useful work, that doesn't need stdio.h?

 

[Willem]

Bartc wrote:
) Is there any program, that does any useful work, that doesn't need stdio.h?

No, but there are bound to be plenty of modules that don't.
Most C programs tend to have more than one source file, you know.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[James Kuyper]

Have you since changed your thinking?

As long as <stdio.h> was the only header required by the entire standard
library, I think that was a legitimate question. I can't remember being
aware of the fact that additional headers were added later. As a result,
I was surprised when pete pointed out that K&R c only used <stdio.h>.
However, I checked my copy of K&R I, and he's right.

I now believe that using multiple headers for a sufficiently large
library was a good idea for two different reasons, one that is obsolete,
and one that is not.

The obsolete reason is that it reduced the compilation time by a
significant amount if you only #included the headers that you actually
needed. Computers have gotten a lot faster since then, and I doubt that
many people compile code on machines with such severe limitations. I
believe that some people do compile code for such machines, but that
they usually use a cross-compiler to do so.

The reason that still applies is name space pollution. As libraries
(standard and otherwise) continue to proliferate, I shouldn't have to be
aware of the hundreds (or even thousands) of different identifiers that
are in use by all of those libraries, so I can avoid using them in a
conflicting way in my program. I should only have to worry about the
identifiers used by the parts of those libraries that I'm actually using.

Having a separate header for each part of the library helps reduce this
problem. It doesn't avoid the problem completely: you still can't use,
as an identifier with external linkage, any identifier that the C
standard lists as an identifier with external linkage in any part of the
C standard libraries, regardless of whether or not you #include the
corresponding header.

 

[James Kuyper]

Probably almost every trivial program too.

Is there any program, that does any useful work, that doesn't need stdio.h?

I've written one or two programs that did nothing but perform a useful
calculation involving numbers that were included in the source code, and
returned an exit value which told me whether or not the result of the
calculation met a specific criterion. These programs made no use of any
library routines. However, I've only done that a few times in the 33
years I've been programming.

 

[Guest]

Subject: "Do we need to continue to include stdio.h in C files ?"

yes

The #include tells the compiler to include information
about the standard input/ouput library and this appears
in many source files.

But, why cannot C link the libraries using the linkers
automatically during linking procedure instead of having these
#includes ?

now who was it that said distinguishing headers from
libraries was pedantic? And that newbies weren't confused...

 

[Stefan Ram]

The obsolete reason is that it reduced the compilation time by a
significant amount if you only #included the headers that you actually

When a build gets large enough or when one is going through
several edit-build-test cycles, this still might be relevant.

Always including »stdio.h« also might be of no use when one is
using a freestanding implementation of C or when one is using
C to write system programs or applications using calls to an
operating system's API. It also might be possible that a
freestanding implementation uses a library that wants to
define its own meaning for common identifiers such as »FILE«.

 

[Richard Tobin]

I learned C very shortly after K&R I first came out. I remember thinking
"If almost every non-trivial C program requires #include <stdio.h>, why
don't they just make it implicit?".

I think it's more accurate to say that almost every trivial C program
needs <stdio.h>. Most non-trivial C programs only need it in some of
the files.

And of course programs not written entirely in standard C may use
quite other methods for i/o.

-- Richard

 

[Stefan Ram]

When a build gets large enough or when one is going through
several edit-build-test cycles, this still might be relevant.
Always including »stdio.h« also might be of no use when one is

Also, »#include <stdio.h«, »#include <cstdio>« (sorry!),
»#include <windows.h>« at the start of a source file can
double as a kind of documentation, giving the experienced
reader an immediate idea of what kind of program this is.

 

[Bartc]

When a build gets large enough or when one is going through
several edit-build-test cycles, this still might be relevant.

Always including »stdio.h« also might be of no use when one is
using a freestanding implementation of C or when one is using
C to write system programs or applications using calls to an

For some of us C's approach seems a little old-fashioned.

Imagine if all C's standard types, operators and keywords were partitioned
into sets and each set needed a header, and you always had to be aware of
which sets were being used and which headers needed to be declared.

It would be a nuisance, which is the case with many of the extra types,
constants and functions that other languages have built-in but C chooses to
put into headers.

(I wouldn't have thought that always including stdio.h, or any of the
standard headers, would cause any additional resources to be used in the
final executable.)

operating system's API. It also might be possible that a
freestanding implementation uses a library that wants to
define its own meaning for common identifiers such as »FILE«.

It sounds unusual enough to warrant special actions when needed, rather than
the other way round (meaning 99% explicit inclusion of stdio.h just so the
other 1% can redefine what's in stdio.h).

(The answer of course is being able to deal with multiple levels of symbols
in include files, but C's preprocessor system is too crude to deal with
this. However the less useful extra scopes inside blocks do seem to be
available (in C99?).)

 

[Dik T. Winter]

> It would be a nuisance, which is the case with many of the extra types,
> constants and functions that other languages have built-in but C chooses to
> put into headers.

Algol 68 also had the extra types, constants and functions not built-in in
the compiler. I have used an Algol 68 compiler where you could compile
with or without the standard environment. Compiling without was necessary
when compiling the standard environment itself.

 

[Guest]

Probably almost every trivial program too.

Is there any program, that does any useful work, that doesn't need stdio.h?

I don't think I've actually seen one, but I've seen ones that come
close.
These tend to be server type applications that did all their i/o via
sockets. If there was a GUI or other user interface it communicated
with that via a socket. Hence 90% of the i/o was not via stdio. Where
this broke down was reading configuration files, logging errors and
startup and shutdown messages.

 

[Ben Bacarisse]

In the category of "if only they had" is if only they had put all
of an include file's identifiers in a struct name space pollution
wouldn't have been nearly as much of a problem. I grant that
writing io.printf rather than printf or math.cos rather that cos
takes more characters, but so what.

That would have needed another change that only came later. In "old
C", a function name was an expression of type "function returning..."
and an expression of this type was required in front of the function
call operator. In other words, you'd have to have written
(*io.printf)("...", ...);

I am not sure when the function call operator switched to taking a
pointer, but it simplified a few things in semantics.

 

[Ben Bacarisse]

pete wrote:
...

I learned C very shortly after K&R I first came out. I remember
thinking "If almost every non-trivial C program requires #include
<stdio.h>, why don't they just make it implicit?".

Speed and memory usage come to mind. On slow machines with little
memory you wanted most modules to compile with as few headers as
possible. With some programs you had to move stuff around between
modules just to get it through the compiler.

 

[Bartc]

Algol 68 also had the extra types, constants and functions not built-in in
the compiler. I have used an Algol 68 compiler where you could compile
with or without the standard environment.

Don't know too many recent languages, but from what I remember of Fortran,
Algol, Cobol and Pascal, they didn't seem to need all this business of
having to declare things that are considered part of the language. And this
was on machines not much more advanced that what C was developed on.

However a lot of other languages I've looked at do seem to be full of Use
and Import and such statements, even for libraries as basic as maths, so I
can only conclude those designers were over-exposed to C.

Compiling without was necessary
when compiling the standard environment itself.

Developing the standard libraries for a language seems rather specialised
and it's simple enough to have a compiler switch to turn off standard
includes when this work is being done.