This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: #include <complex>


>>>>> "Dimitri" == Dimitri PAPADOPOULOS-ORFANOS <papadopo@shfj.cea.fr> writes:

 Dimitri> Manfred Hollstein wrote:
 >> Why not stat the file and silently ignore it if S_IFDIR is set?

 Dimitri> I agree, directories should be silently ignored.

 Dimitri> Still, I think that when processing #include <...>
 Dimitri> directories in $CPLUS_INCLUDE_PATH should be scanned before
 Dimitri> the directories specified on the command line.

 Dimitri> On the other hand, when processing #include "..."  it's ok
 Dimitri> for directories specified on the command line to be scanned
 Dimitri> first.

There are, I think, three issues here that are being mixed together.

1. If I'm including foo, and one of the directories in the search list
contains a foo but it's not a regular file, what should be done?

Reasonable answer is to ignore it (not just directories but also, less
likely, other special files).  This means the search for a matching
regular file will continue with the next search list entry.

2. Ditto but the only match found in the entire search list is a
special file.  What error message should result?

I'd suggest it should *not* be the usual "include file not found"
error because "ls" will show there is a file.  Better to tell the user
that the file was found but it wasn't a regular file.

3. Should the search list order be changed (for #include < > and/or
for #include " ")?

Answer: NFW.  A large fraction of the makefiles in the known universe
depend on the well documented search ordering.  Don't mess with it,
please. 

	paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]