Can header exist without being a file?

Question

In C: The Complete Reference, Herbert Schildt says that

Headers are usually files, but they are not necessarily files. It is permissible for a compiler to predefine the contents of a header internaly. However for all practical purposes, the standard c headers are contained in files that correspond to their names.

How can a header exist without being a file? What's the theme of this passage? Because the .h file extension is used with a header.

For example, you might say `#include "/path/to/some/named/pipe"`. Of course, you would expect that the named pipe always exists for every compilation unit, but ensuring that might be more difficult than it's worth (remember that the first compilation unit to "grab" the named pipe might make close that pipe for later compilation units) — inetknght, Mar 14 '16 at 14:35
I suppose my comment is more regarding `#include` rather than headers specifically though. What more context do you want? — inetknght, Mar 14 '16 at 14:38
@inetknght is correct: "A header is a **standard identifier** that might map to a filename, but need not. [...] As a practical matter, however, C headers are nearly always files." (my emph.) (One still may wonder why "*nearly* always" :P) — Jongware, Mar 14 '16 at 14:40
Not really relevant to the question but a lot of people seem to dislike that book. http://stackoverflow.com/a/579795/646887 — Klas Lindbäck, Mar 14 '16 at 14:44
Maybe he thought that C would have modules by now, the header info in an interface section and so a separate header file would not be necessary. Sounds resonable, since C++ has mod... ohwait, no it hasn't:(( — Martin James, Mar 14 '16 at 14:48
@KlasLindbäck: Peter Seebach's [C: The Complete Nonsense](http://www.seebs.net/c/c_tcn4e.html) is quite a long critical appraisal. And yes, he mentions on a part of Schildt's description of header files, "He gets credit for the 'usually'. Unfortunately, the rest isn't so good." — Jongware, Mar 14 '16 at 14:50
This question is for the C language. The exact same question was asked for the C++ language here: http://stackoverflow.com/questions/27261508/is-a-header-necessarily-a-file — chqrlie, Mar 14 '16 at 14:54
@chqrlie An answer there made a straight quote from the _C_ rationale - why keep another identical question? I'd rather tag that question as C as well. — edmz, Mar 14 '16 at 15:01
@black: indeed this answer is pertinent: http://stackoverflow.com/a/27262904/4593267 but it gives the rationale, not the Standard quote. C and C++ are different enough that answers to precise language related questions like this one need be language specific. — chqrlie, Mar 14 '16 at 15:13

score 6 · Accepted Answer · edited Jun 20 '20 at 09:12

The C Standard does make a difference between header and source files referred to by #include preprocessing directives:

6.10.2 Source file inclusion

Constraints

1 A #include directive shall identify a header or source file that can be processed by the implementation.

Semantics

2 A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.

3 A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original directive.

The compiler may implement a scheme where standard headers are not actually stored as files in the file system. But the directive #include "filename.h" is specified as searching first for a file in a system specific way, and then searching standard headers as if the directive had been #include <filename.h>

Note that the filename extensions .c and .h are purely a convention to distinguish files containing declarations and files containing actual code and data definitions. Nothing in the Standard makes this convention a requirement, beyond the names used for the standard headers. Some people use other conventions with different extensions or no extensions at all for specific needs, but the vast majority of C programmers would regard this as bad practice.

Shafik Yaghmour provided a quote from the C99 Rationale in an answer to a similar question that nails the committees intent on this matter: https://stackoverflow.com/a/27262904/4593267

Lundin · Answer 2 · 2016-03-14T14:49:51.300

4

The C standard explicitly says that a header is a file, so I think not.

6.10.2 Source file inclusion

A #include directive shall identify a header or source file that can be processed by the implementation.

However, what counts as a file for the given system is implementation-defined. It could in theory be a hardware port, a pipe or some some other silliness. Most of the major OS have the possibility to treat ports or pipes as files (for example in Windows, files and hardware ports are opened with the same function.)

edited Mar 14 '16 at 14:49

answered Mar 14 '16 at 14:47

Lundin

195,001
40
254
396

3

In section 7.1.2 "Standard headers" the standards has a footnote `A header is not necessarily a source file, nor are the < and > delimited sequences in header names necessarily valid source file names.`, so the file only refers to "source file", not to header – Marcel Krüger Mar 14 '16 at 14:49
I think this sentence should be parsed as or , not or . The following paragraphs make this distinction more explicit. – chqrlie Mar 14 '16 at 14:49
@zauguin Yes? Foot notes aren't normative in ISO standards. – Lundin Mar 14 '16 at 14:50
@zauguin As I interpret it, the footnote (which is not normative) just wanted to point out that a precise, technical definition of what a file is won't be given for portability's sake. It's not truly needed either, as far as ISO is concerned. – edmz Mar 14 '16 at 14:51
@chqrlie The chapter is called "source file inclusion" though. – Lundin Mar 14 '16 at 14:53
1

@Lundin: indeed! The language of the Standard could be improved to remove this ambiguity. I still think the committee was hinting at embedded headers in the compiler, rather than system specific pseudo-files. – chqrlie Mar 14 '16 at 14:58
1

Anyway, I think there was this big movement during mid 90s, where language committees smoked lots of illegal substances, and then brain-stormed about future computers, that wouldn't have files or file extensions. Somewhere during that movement, all C++ standard library includes had the .h extension removed, in a single, brilliant move to break all existing C++ code. I can see how similar-minded persons would come up with the idea of a header nor being a file. It could perhaps be a unicorn, or the rainbow. – Lundin Mar 14 '16 at 15:09

Basile Starynkevitch · Answer 3 · 2017-12-27T16:37:38.887

An hypothetical C compiler is not required to need a file system. It could process a #include directive otherwise:

it could query a database (IIRC some IBM compiler did that in the 1980s, the database contained a cache of the AST)
it could process standard includes otherwise, that is when it encounters #include <stdio.h> -in certain conditions- change its internal state (per what the standard requires) without accessing any header file. In other words, standard headers could be "builtin".

In practice, all the C compilers I know today are using a file system for headers. But read about precompiled headers in GCC.

BTW, the mention of "header file" in the C11 specification n1570 does not requires a file system (as in usual OSes).

Can header exist without being a file?

3 Answers3