This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: #import future (summary and proposed solutions)
- From: "Timothy J. Wood" <tjw at omnigroup dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 25 Jan 2003 22:10:08 -0800
- Subject: Re: #import future (summary and proposed solutions)
On Saturday, January 25, 2003, at 09:57 PM, Zack Weinberg wrote:
Yes you are. If this pattern doesn't work you're already hosed,
because you have a conflict on the short name of the file itself.
But that's why the file name should not be used for the uniquing
(either in the include guards or by the #import machinery). A 'good
enough' solution that uses the inode and some relatively persistent
filesystem identifier should give you five nines of reliability as
opposed to the five eights I've gotten with include guards :)
Geoff's (re)implementation of #import, as I understand it, will fail
to discover that /usr/include/sys/../time.h and /usr/include/time.h
are in fact the same file, so it will be read twice - and since there
is nothing but the #import check to prevent the compiler from seeing
double declarations, the compiler will see double declarations.
I fail to see how this could possibly fail. You could determine this
by processing the path, dropping directories for each '..' encountered
or you could do a simple stat and see that the inodes and filesystems
are the same.
-tim