Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > limits.h

Reply
Thread Tools

limits.h

 
 
frank
Guest
Posts: n/a
 
      01-15-2010

I read this on the internet:

I am strongly against creating a my-headers.h that simply includes all
the standard header files, when it's clearly defined which standard
headers provide which standard symbols, such as limits.h provides
PATH_MAX.

end quote. Does PATH_MAX have to be defined in limits.h, according to
standard C? I thought it certainly must, until I didn't get a hit for
it in the dinkumware compleat reference.
--
frank
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-15-2010
frank <(E-Mail Removed)> writes:

> I read this on the internet:
>
> I am strongly against creating a my-headers.h that simply includes all
> the standard header files, when it's clearly defined which standard
> headers provide which standard symbols, such as limits.h provides
> PATH_MAX.
>
> end quote. Does PATH_MAX have to be defined in limits.h, according to
> standard C?


No.

> I thought it certainly must, until I didn't get a hit for
> it in the dinkumware compleat reference.


I'd pick the Dinkumware reference too, if I had no other source to go
by. Alternatively, look at the C standard and you'll see no PATH_MAX
there at all (stdio.h defines FILENAME_MAX but that's not the macro in
question).

--
Ben.
 
Reply With Quote
 
 
 
 
Peter Nilsson
Guest
Posts: n/a
 
      01-15-2010
Ben Bacarisse <(E-Mail Removed)> wrote:
> frank <(E-Mail Removed)> writes:
> > Does PATH_MAX have to be defined in limits.h, according to
> > standard C?

>
> No.


Moreover, a conforming implementation must *not* define it in
<limits.h>.

--
Peter
 
Reply With Quote
 
Ersek, Laszlo
Guest
Posts: n/a
 
      01-15-2010
In article <(E-Mail Removed)>, frank <(E-Mail Removed)> writes:
> I read this on the internet:
>
> I am strongly against creating a my-headers.h that simply includes all
> the standard header files, when it's clearly defined which standard
> headers provide which standard symbols, such as limits.h provides
> PATH_MAX.
>
> end quote. Does PATH_MAX have to be defined in limits.h, according to
> standard C? I thought it certainly must, until I didn't get a hit for
> it in the dinkumware compleat reference.


C99 doesn't mention PATH_MAX in

7.10 Sizes of integer types <limits.h>
->
5.2.4.2.1 Sizes of integer types <limits.h>

If you mean the Single UNIX Specification, then PATH_MAX need not be
defined. You may have to use the pathconf() function, the fpathconf()
function, or the getconf utility instead.

SUSv2:
http://www.opengroup.org/onlinepubs/...00_007_349_002

SUSv3:
http://www.opengroup.org/onlinepubs/...ag_13_24_03_02

SUSv4:
http://www.opengroup.org/onlinepubs/...ag_13_23_03_02

If you program for SUSv2: you may want to use _POSIX_PATH_MAX.

If you program for SUSv3 or SUSv4: you may want to use _POSIX_PATH_MAX,
or, if the implementation conforms not only to POSIX, but also the
Single UNIX Specification, _XOPEN_PATH_MAX.

This might be of interest:

Ulrich Drepper - Directory Reading
http://udrepper.livejournal.com/18555.html

Cheers,
lacos
 
Reply With Quote
 
frank
Guest
Posts: n/a
 
      01-15-2010
Richard Heathfield wrote:
> frank wrote:
>>
>> Does PATH_MAX have to be defined in limits.h, according to standard C?

>
> On the contrary, it *must not* be defined there, or in any other
> standard header.
>


When a compiler is directed to look along different paths for limits.h,
it's liable to find more than one.

What I'm trying to put together is how the preprocessor deals with that
situation. Plauger says header inclusion is idempotent. Ok, fine.
Does that mean if you have the identical text in 2 versions of limits.h,
the preprocessor would end at the same state after doing its thing if it
processes either once or thrice?
--
frank
 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      01-15-2010
On Jan 14, 7:55*pm, frank <(E-Mail Removed)> wrote:
> Richard Heathfield wrote:
> > frank wrote:

>
> >> Does PATH_MAX have to be defined in limits.h, according to standard C?

>
> > On the contrary, it *must not* be defined there, or in any other
> > standard header.

>
> When a compiler is directed to look along different paths for limits.h,
> it's liable to find more than one.
>
> What I'm trying to put together is how the preprocessor deals with that
> situation. *Plauger says header inclusion is idempotent. *Ok, fine.
> Does that mean if you have the identical text in 2 versions of limits.h,
> the preprocessor would end at the same state after doing its thing if it
> processes either once or thrice?



Only the standard headers are guaranteed to be idempotent (well,
except for assert.h). You can, of course, make your own headers
idempotent as well, but that's a different issue. Also, there can
only be one copy of each standard header (assuming such a thing
physically exists), and providing an additional one with a standard
name results in undefined behavior.

So there can only be one limits.h (again, there doesn't have to
physically be a file called that), but including it more than once is
harmless.

For non-standard headers, including two headers of the same name, but
in different directories, is no different than if they had different
names - it's just the contents of the specified file that gets pasted
into your source code at that point. And whatever the effect of
pasting it in two identical - or different - copies is, is what it is.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-15-2010
frank <(E-Mail Removed)> writes:
> Richard Heathfield wrote:
>> frank wrote:
>>>
>>> Does PATH_MAX have to be defined in limits.h, according to standard C?

>>
>> On the contrary, it *must not* be defined there, or in any other
>> standard header.

>
> When a compiler is directed to look along different paths for
> limits.h, it's liable to find more than one.


When you write

#include <limits.h>

in your program, the compiler must find the correct version (which
might not even be a C source file).

> What I'm trying to put together is how the preprocessor deals with
> that situation. Plauger says header inclusion is idempotent. Ok,
> fine. Does that mean if you have the identical text in 2 versions of
> limits.h, the preprocessor would end at the same state after doing its
> thing if it processes either once or thrice?


If you have files named "limits.h" in two different locations,
they aren't necessarily two different "versions" of limits.h;
they may just be two different files that happen to have the same
name. If you tweak your compiler's options so it finds something
other than the usual copy of the limits.h header when you write
"#include <limits.h>", and if that other copy doesn't meet the
standard's requirements for what's contained in that header, then
your tweaking has made your compiler non-conforming. How it then
behaves is entirely outside the scope of the standard.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      01-15-2010
On 2010-01-15, Richard Heathfield <(E-Mail Removed)> wrote:
> If that's true (and I have no reason not to believe you), it is
> impossible for any implementation to conform (simultaneously) to both
> ISO 9899 and POSIX.


Yes. POSIX pollutes the namespace. As a result, if I want to write
reasonably portable code, I avoid the POSIX-reserved namespace hunks
too.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-15-2010
Seebs <(E-Mail Removed)> writes:
> On 2010-01-15, Richard Heathfield <(E-Mail Removed)> wrote:
>> If that's true (and I have no reason not to believe you), it is
>> impossible for any implementation to conform (simultaneously) to both
>> ISO 9899 and POSIX.

>
> Yes. POSIX pollutes the namespace. As a result, if I want to write
> reasonably portable code, I avoid the POSIX-reserved namespace hunks
> too.


Isn't that what the _POSIX_C_SOURCE macro is for?

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      01-15-2010
On 2010-01-15, Keith Thompson <(E-Mail Removed)> wrote:
> Isn't that what the _POSIX_C_SOURCE macro is for?


Yeah, but my confidence that an arbitrary system will actually do that
all correctly is low, so I avoid clashing with those names unless I'm doing
it on purpose.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments