[Bug c/40442] New: Option -I and POSIX conformance (c99 utility)

[Bug c/40442] New: Option -I and POSIX conformance (c99 utility)

[vincent at vinc17 dot org]

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

[Bug c/40442] Option -I and POSIX conformance (c99 utility)

[joseph at codesourcery dot com]

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

[Bug c/40442] Option -I and POSIX conformance (c99 utility)

[vincent at vinc17 dot org]

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

[Bug c/40442] Option -I and POSIX conformance (c99 utility)

[joseph at codesourcery dot com]

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

[Bug c/40442] Option -I and POSIX conformance (c99 utility)

[vincent at vinc17 dot org]

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

[Bug c/40442] Option -I and POSIX conformance (c99 utility)

[joseph at codesourcery dot com]

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

[Bug c/40442] Option -I and POSIX conformance (c99 utility)

[jsm28 at gcc dot gnu dot org]

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

[Bug c/40442] Option -I and POSIX conformance (c99 utility)

[vincent at vinc17 dot org]

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