By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 1,834 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

Header locations

P: n/a
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.

Apr 24 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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.

Apr 24 '06 #2

P: n/a
On 23 Apr 2006 18:56:25 -0700, "mdh" <md**@comcast.net> wrote in
comp.lang.c:
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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Apr 24 '06 #3

P: n/a
mdh

Jack Klein wrote:
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.


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

I thanketh thee!!!

Apr 24 '06 #4

P: n/a
Jack Klein <ja*******@spamcop.net> wrote:
On 23 Apr 2006 18:56:25 -0700, "mdh" <md**@comcast.net> wrote in
comp.lang.c:
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.


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
Apr 24 '06 #5

P: n/a
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Jack Klein <ja*******@spamcop.net> wrote:
On 23 Apr 2006 18:56:25 -0700, "mdh" <md**@comcast.net> wrote in
comp.lang.c:
> 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.


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.


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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 24 '06 #6

P: n/a
Keith Thompson <ks***@mib.org> wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Jack Klein <ja*******@spamcop.net> wrote:
On 23 Apr 2006 18:56:25 -0700, "mdh" <md**@comcast.net> wrote in
comp.lang.c:

> 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.

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.


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
Apr 24 '06 #7

P: n/a
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.org> wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
> Jack Klein <ja*******@spamcop.net> wrote:
>
>> On 23 Apr 2006 18:56:25 -0700, "mdh" <md**@comcast.net> wrote in
>> comp.lang.c:
>>
>> > 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.
>>
>> 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.


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).


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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 24 '06 #8

P: n/a
On Mon, 24 Apr 2006 07:08:18 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote in comp.lang.c:
Jack Klein <ja*******@spamcop.net> wrote:
On 23 Apr 2006 18:56:25 -0700, "mdh" <md**@comcast.net> wrote in
comp.lang.c:
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.


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


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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Apr 25 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.