This is the mail archive of the
mailing list for the Cygwin project.
Re: New platform independent problem
-----BEGIN PGP SIGNED MESSAGE-----
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.
> 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
>>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 email@example.com
-----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
-----END PGP SIGNATURE-----
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html