public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/40442] New: Option -I and POSIX conformance (c99 utility)
@ 2009-06-15 0:18 vincent at vinc17 dot org
2009-06-15 1:01 ` [Bug c/40442] " joseph at codesourcery dot com
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: vincent at vinc17 dot org @ 2009-06-15 0:18 UTC (permalink / raw)
To: gcc-bugs
GCC doesn't seem to provide a c99 utility, but some vendors provide one based
on gcc. And the GCC behavior can make POSIX conformance difficult to obtain.
Here's the difference.
POSIX.1-2008 says[*]:
-I directory
Change the algorithm for searching for headers whose names are not
absolute pathnames to look in the directory named by the directory
pathname before looking in the usual places. Thus, headers whose
names are enclosed in double-quotes ( "" ) shall be searched for
first in the directory of the file with the #include line, then in
directories named in -I options, and last in the usual places. For
headers whose names are enclosed in angle brackets ( "<>" ), the
header shall be searched for only in directories named in -I
options and then in the usual places. Directories named in -I
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
options shall be searched in the order specified. Implementations
shall support at least ten instances of this option in a single
c99 command invocation.
[*] http://www.opengroup.org/onlinepubs/9699919799/utilities/c99.html
So, the directories specified by -I should have the precedence over the usual
places. However, this is not the behavior of gcc; from the gcc 4.3.2 man page:
-I dir
Add the directory dir to the list of directories to be searched for
header files. Directories named by -I are searched before the
standard system include directories. If the directory dir is a
standard system include directory, the option is ignored to ensure
that the default search order for system directories and the
special treatment of system headers are not defeated . If dir
begins with "=", then the "=" will be replaced by the sysroot
prefix; see --sysroot and -isysroot.
As you can see, there is a difference for standard system include directories,
for which the option is ignored.
I suggest that GCC adds a new option to switch to the POSIX specifications.
FYI, I've reported the bug against Debian here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533124
--
Summary: Option -I and POSIX conformance (c99 utility)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
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 ` 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
end of thread, other threads:[~2009-11-23 4:51 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).