Re: #import future (summary and proposed solutions)

["Timothy J. Wood" <tjw at omnigroup dot com>]

On Saturday, January 25, 2003, at 11:47  PM, Zack Weinberg wrote:
> Any *one* of these problems would be enough to prohibit the use of
> inode numbers for file disambiguation in GCC as distributed by the
> FSF.  Again, if Apple is prepared to guarantee that none of these
> problems will ever manifest on OSX, good for them.
  Wow -- I wasn't aware there were filesystems that ... interesting :)

  One alternative that would preserve the 'optimize common case' would 
be to detect whether the header file is on such a filesystem and then 
fall back to an alternative implementation (content based, I guess).

  For PCH, you could just refuse to build a PCH located on or 
containing files on these filesystems (or warn that the PCH will not 
actually precompile anything but will just include the original 
header).  Since I'm not familiar with these filesystems you mention, I 
can't say how common they are -- if they are rare, this seems like a 
reasonable and correct approach.

> And I'm not sure what you mean by 'fs identifier'.
  I mean any blob of information that uniquely identifies a mounted 
filesystem from the other currently mounted filesystems.  So, you could 
store "nfs://hostname/mount-point" or 
"hfs://volume-name@raw-device/mount-point".  Without some guarantee 
from the filesystem itself, no guarantees about the global uniqueness 
of such an identifier could be made.


> Sure, but a mechanism like #import, where false positives or negatives
> cause correct programs to be rejected, has to work in all the crazy
> edge cases or it's worse than useless.
  I can't disagree with this in principle, but I still think that 
include guards are more likely to cause problems due to their manual 
nature.

  ... now that I think about it, the content based identity scheme 
seems pretty shaky too.  Consider the case of DOS v. Mac v. Unix line 
endings, or maybe  someday GCC will support multiple string encodings 
(UTF-8 vs UCS-16 vs ISO Latin 1) ... should two copies of a header file 
that differ only in their superficial textual encoding both get 
included?   How much parsing would a content based system be willing to 
do to consider files 'identical' without have _any_ possibility of 
false positives or negatives?

  I suppose if #import ever goes get removed, it won't be the end of 
the world.... I'll just have to pester Apple into making Project 
Builder automatically generate UUID-containing header guards.  I'm sure 
not interesting it doing it by hand :)

-tim