Header locations

[mdh]

I have spent a few hours trying to figure this out...so may I ask the
group....apologize if it is in the FAQ...I have been unable to find
it..but would gladly be directed.

When one "includes" for example

#include <limits.h>

in a "Standard tool" app, where exactly is the file "limits.h?". A
search in terminal reveals many.

I am looking for the file contain that contains all the symbolic
constants for integers and floats.

Thanks in advance.

 

[mdh]

Sorry, included some non-relevant info.

I have spent a few hours trying to figure this out...so may I ask the
group.

When one "includes" for example

#include <limits.h>


I am looking for the file contain that contains all the symbolic
constants for integers and floats.

Thanks in advance.

 

[Jack Klein]

I have spent a few hours trying to figure this out...so may I ask the
group....apologize if it is in the FAQ...I have been unable to find
it..but would gladly be directed.

When one "includes" for example

#include <limits.h>

in a "Standard tool" app, where exactly is the file "limits.h?". A
search in terminal reveals many.

I am looking for the file contain that contains all the symbolic
constants for integers and floats.

Thanks in advance.

The C standard does not control or define, and is completely agnostic
to, file systems and their directory structures. So it does not
specify these things except in a manner that will not help you.

It states that there are two implementation-defined set of places
searched for #include directives. One is for those of the type
#include <name>, and the other is for those of the type #include
"name".

It does state that if a search for type #include "name" in its normal
set of places fails, the compiler must then search for it in the
places it would as if it had been written #include <name>, before
giving up.

So if you want to know where your particular compiler searches for
headers and files specified in #include directives, you need a group
that supports your specific compiler/operating system combination to
help you out. The C language sayeth not.

 

[mdh]

headers and files specified in #include directives, you need a group
that supports your specific compiler/operating system combination to
help you out. The C language sayeth not.

Ok....that makes sense, or as the bard would say.....

I thanketh thee!!!

 

[Richard Bos]

The C standard does not control or define, and is completely agnostic
to, file systems and their directory structures. So it does not
specify these things except in a manner that will not help you.

It states that there are two implementation-defined set of places
searched for #include directives. One is for those of the type
#include <name>, and the other is for those of the type #include
"name".

And note that while #include "name" includes the source file called
"name" (which can therefore be assumed to be a real file), #include
<name> includes the _header_ called "name", implying that it need not
even be an actual file on your disk.

Richard

 

[Keith Thompson]

And note that while #include "name" includes the source file called
"name" (which can therefore be assumed to be a real file), #include
<name> includes the _header_ called "name", implying that it need not
even be an actual file on your disk.

Except that if #include "name" fails to find a file called "name", it
falls back to searching in the location(s) normally searched for
#include <name>.

For example, #include "stdio.h" will, unless you have another file
called "stdio.h", include the standard stdio.h header, which may or
may not be a file.

 

[Richard Bos]

Except that if #include "name" fails to find a file called "name", it
falls back to searching in the location(s) normally searched for
#include <name>.

For example, #include "stdio.h" will, unless you have another file
called "stdio.h", include the standard stdio.h header, which may or
may not be a file.

True. But not, significantly, the other way 'round.

Note also that it's undefined behaviour to actually try to make use of
this feature (7.1.2#3).

Richard

 

[Keith Thompson]

True. But not, significantly, the other way 'round.

Note also that it's undefined behaviour to actually try to make use of
this feature (7.1.2#3).

Good point. On the other hand, an implementation can provide a
non-file header in a location searched by <>. It can even allow users
to create such headers (in a completely system-specific way). For
example,

#include "foobar.h"

might refer to a header provided by the implementation (or even one
not provided by the implementation) that's not a file.

 

[Jack Klein]

And note that while #include "name" includes the source file called
"name" (which can therefore be assumed to be a real file), #include
<name> includes the _header_ called "name", implying that it need not
even be an actual file on your disk.

Richard

Well, yes and no.

I have literally never seen a compiler that did not come with the more
than the 15 or 18 or 24 standard headers required by the version of
the C standard that it conformed to. In every case, these additional
headers are stored in the same place, or perhaps in a subdirectory of
the same place, that the standard headers are stored.

And in every such case, the proper way to include them is the #include
<name> form. Of course, the standard is gloriously ambiguous about
what happens if your source has something like:

#include <goofy.h>

Nowhere does it state that the <> notation may only be used for
standard headers, but it is only the footnote in 7.1.2 Standard
headers that states that "A header is not necessarily a source file".

Since this appears in the section defining standard headers, but
itself does not specify "standard headers" but all headers, does it
apply to non-standard headers?

Technically speaking, the standard doesn't define anything at all
about non-standard headers, but seems to allow for them.