X-Spam-Check-By: sourceware.org Message-ID: <43D0F12A.4000202@byu.net> Date: Fri, 20 Jan 2006 07:18:18 -0700 From: Eric Blake User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Eli Zaretskii CC: cygwin AT cygwin DOT com, henman AT it DOT to-be DOT co DOT jp, emacs-devel AT gnu DOT org Subject: Re: New platform independent problem References: <43D0797C DOT 1030604 AT it DOT to-be DOT co DOT jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com -----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 AT byu DOT 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----- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/