* [Bug c/40442] Option -I and POSIX conformance (c99 utility)
2009-06-15 0:18 [Bug c/40442] New: Option -I and POSIX conformance (c99 utility) vincent at vinc17 dot org
@ 2009-06-15 1:01 ` joseph at codesourcery dot com
2009-06-15 2:08 ` vincent at vinc17 dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: joseph at codesourcery dot com @ 2009-06-15 1:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from joseph at codesourcery dot com 2009-06-15 01:01 -------
Subject: Re: New: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
> As you can see, there is a difference for standard system include directories,
> for which the option is ignored.
This sounds like it is mainly a defect in POSIX; it should make it
undefined behavior if you pass a -I option pointing to any directory that
contains a file with the same name as any standard header (recall that
standard headers do not need to correspond to physical files with the same
name). Changing the search order of system directories is clearly liable
to break any implementation that deliberately has more than one file of a
name for some reason (maybe GCC's limits.h and glibc's version can cope
with either order of inclusion, but I see no reason for a requirement for
implementations to follow that), and pointing to a user's own file with
the same name as a standard header is bound to cause breakage. C99 has
such an undefined behavior rule in 7.1.2#3; POSIX just needs to extend it
to the POSIX system headers as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/40442] Option -I and POSIX conformance (c99 utility)
2009-06-15 0:18 [Bug c/40442] New: Option -I and POSIX conformance (c99 utility) vincent at vinc17 dot org
2009-06-15 1:01 ` [Bug c/40442] " joseph at codesourcery dot com
@ 2009-06-15 2:08 ` vincent at vinc17 dot org
2009-06-15 10:57 ` joseph at codesourcery dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: vincent at vinc17 dot org @ 2009-06-15 2:08 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from vincent at vinc17 dot org 2009-06-15 02:08 -------
This may be true for standard headers, but system directories don't contain
only standard headers: in practice, they generally also contain additional
libraries. And for instance, a -I/usr/include can be useful to override
headers/libraries installed in /usr/local/{include,lib}.
Then perhaps gcc (and POSIX) should make a difference between standard headers
and other headers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/40442] Option -I and POSIX conformance (c99 utility)
2009-06-15 0:18 [Bug c/40442] New: Option -I and POSIX conformance (c99 utility) vincent at vinc17 dot org
2009-06-15 1:01 ` [Bug c/40442] " joseph at codesourcery dot com
2009-06-15 2:08 ` vincent at vinc17 dot org
@ 2009-06-15 10:57 ` joseph at codesourcery dot com
2009-06-15 11:59 ` vincent at vinc17 dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: joseph at codesourcery dot com @ 2009-06-15 10:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from joseph at codesourcery dot com 2009-06-15 10:57 -------
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
> This may be true for standard headers, but system directories don't contain
> only standard headers: in practice, they generally also contain additional
> libraries. And for instance, a -I/usr/include can be useful to override
> headers/libraries installed in /usr/local/{include,lib}.
If you have modified the implementation (by putting headers/libraries in
standard directories where those headers/libraries were not provided by
the implementation in those versions in those directories, for example),
you are very definitely outside the scope of POSIX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/40442] Option -I and POSIX conformance (c99 utility)
2009-06-15 0:18 [Bug c/40442] New: Option -I and POSIX conformance (c99 utility) vincent at vinc17 dot org
` (2 preceding siblings ...)
2009-06-15 10:57 ` joseph at codesourcery dot com
@ 2009-06-15 11:59 ` vincent at vinc17 dot org
2009-06-15 13:07 ` joseph at codesourcery dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: vincent at vinc17 dot org @ 2009-06-15 11:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 -------
(In reply to comment #3)
> If you have modified the implementation (by putting headers/libraries in
> standard directories where those headers/libraries were not provided by
> the implementation in those versions in those directories, for example),
> you are very definitely outside the scope of POSIX.
I'm not sure I understand what you mean. But the existing practice is that
additional headers/libraries (i.e. not those defined by the C standard)
provided by the vendor are stored under /usr/{include,lib}. And I don't think
this goes against POSIX. Concerning /usr/local, the FHS says:
The /usr/local hierarchy is for use by the system administrator when
installing software locally.
So, it should be safe to add libraries there. And again, this is the existing
practice.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/40442] Option -I and POSIX conformance (c99 utility)
2009-06-15 0:18 [Bug c/40442] New: Option -I and POSIX conformance (c99 utility) vincent at vinc17 dot org
` (3 preceding siblings ...)
2009-06-15 11:59 ` vincent at vinc17 dot org
@ 2009-06-15 13:07 ` joseph at codesourcery dot com
2009-11-22 19:55 ` jsm28 at gcc dot gnu dot org
2009-11-23 4:51 ` vincent at vinc17 dot org
6 siblings, 0 replies; 8+ messages in thread
From: joseph at codesourcery dot com @ 2009-06-15 13:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from joseph at codesourcery dot com 2009-06-15 13:06 -------
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
> ------- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 -------
> (In reply to comment #3)
> > If you have modified the implementation (by putting headers/libraries in
> > standard directories where those headers/libraries were not provided by
> > the implementation in those versions in those directories, for example),
> > you are very definitely outside the scope of POSIX.
>
> I'm not sure I understand what you mean. But the existing practice is that
> additional headers/libraries (i.e. not those defined by the C standard)
> provided by the vendor are stored under /usr/{include,lib}. And I don't think
> this goes against POSIX. Concerning /usr/local, the FHS says:
>
> The /usr/local hierarchy is for use by the system administrator when
> installing software locally.
>
> So, it should be safe to add libraries there. And again, this is the existing
> practice.
It is not, however, safe to add libraries there that in any way conflict
with the libraries provided by the system in /usr (such as different
versions of the same libraries).
A POSIX-conforming system should have a POSIX conformance document that
explains the circumstances under which the claims of POSIX conformance are
made. Those circumstances will include restrictions on any modification
of system directories, such as limits on the contents of files in /etc for
the system to be conforming and limits on what may go in /usr/local if
some POSIX applications search that directory by default. This document
is nothing to do with GCC on its own; it has to be provided by the system
integrator and describes properties of the whole system. If the document
for the POSIX system you are using is inadequate, you should raise that
with the system integrator (and if necessary with whoever certified
conformance). And if POSIX does not render undefined options that have
the effect of changing internal configuration details of applications,
where those details have to be in a particular form for conformance (for
example, conformance requiring header and library directories in a
particular order), this is a bug in POSIX. -I or -L options pointing to
any of an implementation-defined set of system directories, or any
directory with duplicates of headers or libraries in system directories,
should be undefined behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/40442] Option -I and POSIX conformance (c99 utility)
2009-06-15 0:18 [Bug c/40442] New: Option -I and POSIX conformance (c99 utility) vincent at vinc17 dot org
` (4 preceding siblings ...)
2009-06-15 13:07 ` joseph at codesourcery dot com
@ 2009-11-22 19:55 ` jsm28 at gcc dot gnu dot org
2009-11-23 4:51 ` vincent at vinc17 dot org
6 siblings, 0 replies; 8+ messages in thread
From: jsm28 at gcc dot gnu dot org @ 2009-11-22 19:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from jsm28 at gcc dot gnu dot org 2009-11-22 19:55 -------
Not a GCC bug, the POSIX list generally agreed the effects of reordering
system directories should be unspecified or undefined.
--
jsm28 at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug c/40442] Option -I and POSIX conformance (c99 utility)
2009-06-15 0:18 [Bug c/40442] New: Option -I and POSIX conformance (c99 utility) vincent at vinc17 dot org
` (5 preceding siblings ...)
2009-11-22 19:55 ` jsm28 at gcc dot gnu dot org
@ 2009-11-23 4:51 ` vincent at vinc17 dot org
6 siblings, 0 replies; 8+ messages in thread
From: vincent at vinc17 dot org @ 2009-11-23 4:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from vincent at vinc17 dot org 2009-11-23 04:51 -------
(In reply to comment #6)
> Not a GCC bug, the POSIX list generally agreed the effects of reordering
> system directories should be unspecified or undefined.
What the POSIX list says does not matter if this doesn't go further. What's
important is what the POSIX standard says. So, I've opened the following bug so
that the POSIX standard can be changed:
http://austingroupbugs.net/view.php?id=187
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
^ permalink raw reply [flat|nested] 8+ messages in thread