comp.lang.c - 17 new messages in 4 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* limits.h - 10 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/5a3024cfbe9312f5?hl=en
* The undefinedness of a common expression. - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/bdae87d399a9442e?hl=en
* A tool that suggests optimized logic for a piece of code/module/function - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/8dc0c7e3c216aa24?hl=en
* function not returning a value - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/60dc2ec18a00c85a?hl=en

==============================================================================
TOPIC: limits.h
http://groups.google.com/group/comp.lang.c/t/5a3024cfbe9312f5?hl=en
==============================================================================

== 1 of 10 ==
Date: Thurs, Jan 14 2010 6:24 pm
From: William Ahern

frank <frank@example.invalid> wrote:
<snip>
> 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.

Probably because PATH_MAX is defined by POSIX (and perhaps other standards
I'm unaware of). POSIX says that limits.h must provide PATH_MAX.

== 2 of 10 ==
Date: Thurs, Jan 14 2010 6:28 pm
From: Keith Thompson

frank <frank@example.invalid> 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) kst-u@mib.org <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"

== 3 of 10 ==
Date: Thurs, Jan 14 2010 6:35 pm
From: Richard Heathfield

William Ahern wrote:

<snip>

> POSIX says that limits.h must provide PATH_MAX.

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 4 of 10 ==
Date: Thurs, Jan 14 2010 6:37 pm
From: Seebs

On 2010-01-15, Richard Heathfield <rjh@see.sig.invalid> 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 / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 5 of 10 ==
Date: Thurs, Jan 14 2010 7:49 pm
From: William Ahern

Richard Heathfield <rjh@see.sig.invalid> wrote:
> William Ahern wrote:

> <snip>

> > POSIX says that limits.h must provide PATH_MAX.

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

Well, as lacos pointed out I was wrong about PATH_MAX.

A definition of one of the symbolic constants in the following list
shall be omitted from the <limits.h> header on specific
implementations where the corresponding value is equal to or greater
than the stated minimum, but where the value can vary depending on
the file to which it is applied. The actual value supported for a
specific pathname shall be provided by the pathconf() function.

pathconf() is defined in <unistd.h>.

But there are other macros, like _POSIX_PATH_MAX (a minimum spoken of
above), which are required. To wit:

The <limits.h> header shall define the following symbolic constants
with the values shown

The preamble to the <limits.h> section also states "[t]he <limits.h> header
shall define macros and symbolic constants for various limits."

== 6 of 10 ==
Date: Thurs, Jan 14 2010 8:00 pm
From: Keith Thompson

Seebs <usenet-nospam@seebs.net> writes:
> On 2010-01-15, Richard Heathfield <rjh@see.sig.invalid> 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) kst-u@mib.org <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"

== 7 of 10 ==
Date: Thurs, Jan 14 2010 8:42 pm
From: Seebs

On 2010-01-15, Keith Thompson <kst-u@mib.org> 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 / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 8 of 10 ==
Date: Thurs, Jan 14 2010 9:41 pm
From: frank

robertwessel2@yahoo.com wrote:
> On Jan 14, 7:55 pm, frank <fr...@example.invalid> 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.

Alright, thanks robert. I guess I've been trying to reconcile some odd
things today. Let me ask this:

#include <limits.h>
#include <limits.h>
...

Does only one copy of limits.h get pasted in at the top of the program?
--
frank

== 9 of 10 ==
Date: Thurs, Jan 14 2010 11:02 pm
From: frank

Richard Heathfield wrote:
> William Ahern wrote:
>
> <snip>
>
>> POSIX says that limits.h must provide PATH_MAX.
>
> 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.
>

So it would seem, but the PATH_MAX on the contemporary posix side isn't just
#define PATH_MAX 512

, else this line wouldn't have failed today:
char pathName[PATH_MAX + 1];

I think this is now deprecated, and PATH_MAX is some type of subvariable
after a pathconf call, but my misapprehension here is palpable.
--
frank

== 10 of 10 ==
Date: Thurs, Jan 14 2010 11:24 pm
From: "robertwessel2@yahoo.com"

On Jan 14, 11:41 pm, frank <fr...@example.invalid> wrote:
> robertwess...@yahoo.com wrote:
> > On Jan 14, 7:55 pm, frank <fr...@example.invalid> 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.
>
> Alright, thanks robert. I guess I've been trying to reconcile some odd
> things today.  Let me ask this:
>
> #include <limits.h>
> #include <limits.h>
> ...
>
> Does only one copy of limits.h get pasted in at the top of the program?

Well, if you were including something other than a standard header (or
assert.h), and not making use of non-standard extensions, you would
certainly get two copies. It's a bit more complicated for the
standard headers.

The important thing is that limits.h, and the other standard headers
(again excepting assert.h), are written/implemented in such a way that
it doesn't make any difference that you included them twice.
Basically the most common approach is to put some sort of guard that
causes the second (and subsequent) includes to do nothing. The
typical guard macros:

#ifndef _LIMITS_H_GUARD
#define _LIMITS_H_GUARD
#define INT_MAX...
...