This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: #import future (summary and proposed solutions)


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

> On Saturday, January 25, 2003, at 10:37  PM, Zack Weinberg wrote:
>> 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).
>
>    Is this because inodes get reused, or is there some other common
> problem?

Some file systems don't have inode numbers at all.
Some file systems have inode numbers that change every time you remount
the partition.
Some file systems have inode numbers that change every time you close
and reopen a file.
Some operating systems do not provide meaningful inode or device
numbers to user space.

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.

(The reader is of course aware that inode numbers are used to remove
duplicate directories from the #include search path.  The problems
listed above do also arise in that context, but the only penalty for
getting it wrong is wasted time, so it's not a problem the way #import
malfunction is.)

>  If you store an fs identifier and the creation time and inode

File systems that have meaningful inode numbers tend *not* to have
meaningful creation times stored on disk.

And I'm not sure what you mean by 'fs identifier'.

[...]
>    The overwhelmingly common case is the average developer writing
> code at one workstation on one local filesystem -- not the build farm
> or the dev tool maintainer or NFS or any of these other crazy edge
> cases.

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.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]