From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Blake Newsgroups: gmane.os.cygwin,gmane.emacs.devel Subject: Re: New platform independent problem Date: Fri, 20 Jan 2006 07:18:18 -0700 Message-ID: <43D0F12A.4000202@byu.net> References: <43D0797C.1030604@it.to-be.co.jp> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1137766728 8552 80.91.229.2 (20 Jan 2006 14:18:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 Jan 2006 14:18:48 +0000 (UTC) Cc: cygwin@cygwin.com, henman@it.to-be.co.jp, emacs-devel@gnu.org Original-X-From: cygwin-return-117762-goc-cygwin=m.gmane.org@cygwin.com Fri Jan 20 15:18:45 2006 Return-path: Envelope-to: goc-cygwin@gmane.org Original-Received: from sourceware.org ([209.132.176.174]) by ciao.gmane.org with smtp (Exim 4.43) id 1Ezx64-0006Dk-Q6 for goc-cygwin@gmane.org; Fri, 20 Jan 2006 15:18:37 +0100 Original-Received: (qmail 18678 invoked by alias); 20 Jan 2006 14:18:31 -0000 Original-Received: (qmail 18670 invoked by uid 22791); 20 Jan 2006 14:18:30 -0000 X-Spam-Check-By: sourceware.org Original-Received: from rwcrmhc14.comcast.net (HELO rwcrmhc12.comcast.net) (216.148.227.89) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Jan 2006 14:18:28 +0000 Original-Received: from [192.168.0.100] (c-24-10-241-225.hsd1.ut.comcast.net[24.10.241.225]) by comcast.net (rwcrmhc14) with ESMTP id <200601201418200140023enae>; Fri, 20 Jan 2006 14:18:25 +0000 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) Original-To: Eli Zaretskii In-Reply-To: X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Xref: news.gmane.org gmane.os.cygwin:73982 gmane.emacs.devel:49319 Archived-At: -----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-----