Re: New platform independent problem

[Eric Blake <ebb9@byu.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Eli Zaretskii on 1/20/2006 6:56 AM:
> 
>>Frankly, many programs expect that if d_ino is present, it has the correct
>>value (i.e., the same as st_ino).
> 
> 
> Which programs expect that, besides the two Chris mentioned?

Several of the coreutils expect that if d_ino is non-zero, it matches
st_ino.  This is in addition to findutils and bash.  But it is probably as
easy to teach programs that a sentinel value means fall back on st_ino as
it is to teach programs to not expect d_ino to exist.

>  My
> experience is the other way around: that d_ino is rarely used.

Which is why it is prohibitively expensive for cygwin to populate it with
the correct value on WinNT and Win2K; too few applications use d_ino to
make it worth doing the Windows equivalent of stat during the readdir() to
correctly populate the d_ino member.  But if we are going to populate
d_ino, it had better either be st_ino (so we aren't lying), or a sentinel
that makes it obvious that st_ino should be used instead (either 0 or -1).
 Fortunately, Win9x and WinXP had non-prohibitive costs to making d_ino
match st_ino.

> 
> 
>>Having the member and not setting it correctly is essentially lying
>>to the application.  Is it so bad for Cygwin to be honest?
> 
> 
> What is bad is to have dirent.h, but not some of the struct members it
> calls for.

POSIX permits implementations to not have d_ino.  In other words, when it
comes to dirent.h, cygwin is fully POSIX-compliant to not have a d_ino
member, and applications had better not assume that d_ino exists.

> 
> It's bad mantra for an application to use a symbol that starts with
> "__", since those symbols are reserved for the library implementation.

My understanding is that leading __ is reserved for the IMPLEMENTATION in
general, not just the library implementation; cygwin is part of the
implementation.  The goal here it to make sure that cygwin does not
pollute the namespace of a compliant app, since the rule is that a
compliant app can use any symbol not reserved by the standards that does
not start with __ without worry of conflict.  And no one has complained
yet that __deprecated_d_ino causes a conflict to a library.

> 
> 
>>Though why would a program refer to d_ino if it doesn't expect to do
>>anything with its content is beyond me.
> 
> 
> Emacs cares that d_ino is non-zero, meaning that this direntry is not
> empty, but otherwise the value of d_ino is not important.

What platforms use d_ino==0 to mean an empty entry, rather than an entry
where st_ino must be checked?  Is it worth introducing -1 as the cygwin
sentinel for non-empty entry, but where st_ino must be consulted, rather
than 0 as the sentinel?

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD0PEq84KuGfSFAYARApZPAJ9jDeUsHhMB59OIDUSzoqyhnSIrHACePz0F
/ENdWA/qbuGIYpCIEpKAv9A=
=gySC
-----END PGP SIGNATURE-----