This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: #include <complex>
- To: papadopo at shfj dot cea dot fr
- Subject: Re: #include <complex>
- From: Paul Koning <pkoning at xedia dot com>
- Date: Thu, 5 Feb 1998 12:09:31 -0500
- Cc: egcs-bugs at cygnus dot com
- References: <199802051630.RAA07230@broceliande.shfj.cea.fr>
>>>>> "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