Re: #import future (summary and proposed solutions)

[Russ Allbery <rra at stanford dot edu>]

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

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

This is extremely difficult to detect at run-time.

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

They may be rare in the overall scheme of things, but at particular sites
they're extremely common.  For example, we use AFS; everything we do, just
about, is in AFS.  And in AFS, inode numbers are per volume, not unique
across the whole file system (which would be impossible; AFS is a large
distributed file system, not just some single disk), and a given site has
tens of thousands of volumes.  Without using AFS API calls (and you really
don't want to go there, believe me), there's no way to uniquely recognize
a particular file in AFS.

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

When you try to obtain this information, you're actively working against
the whole intention of a file system, which is to provide transparent
access to the bits to applications without the applications having to care
what the storage format and access method is.  That's one of the reasons
why it's tricky to do this.

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

My experience is that they're essentially universal in C programming and
they work quite reliably.  But there have been a lot of years to fix them.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>