Re: #import future (summary and proposed solutions)

[Zack Weinberg <zack at codesourcery dot com>]

"Timothy J. Wood" <tjw@omnigroup.com> writes:

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

In a perfect world, file system designers would believe that stable
inode numbers are a Good Thing.  As it is, they're basically useless
(to FSF GCC; if Apple is prepared to guarantee that inode numbers are
meaningful in all OSX-supported file systems, good on them).

They are especially useless in the context of PCH, for the reasons
outlined by Geoff.

Checksums are worth considering.  Care to implement them and find out
what kind of a performance hit they involve?

By the way, if you can think of an approach that will work reliably,
I'm happy to change the #ifndef-wrapper logic to use it too (thus
making your clashing-guard problem go away).

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

Geoff's reimplementation, unless I'm seriously confused, did neither
of these things.  What we have right now does get this right, but can
still be fooled by either variety of link.

zw