From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.os.cygwin,gmane.emacs.devel Subject: Re: New platform independent problem Date: Fri, 20 Jan 2006 15:56:49 +0200 Message-ID: References: <43D0797C.1030604@it.to-be.co.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1137765439 3585 80.91.229.2 (20 Jan 2006 13:57:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 Jan 2006 13:57:19 +0000 (UTC) Cc: henman@it.to-be.co.jp, emacs-devel@gnu.org Original-X-From: cygwin-return-117757-goc-cygwin=m.gmane.org@cygwin.com Fri Jan 20 14:57:17 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 1EzwlC-0000od-1u for goc-cygwin@gmane.org; Fri, 20 Jan 2006 14:57:02 +0100 Original-Received: (qmail 32192 invoked by alias); 20 Jan 2006 13:56:55 -0000 Original-Received: (qmail 32184 invoked by uid 22791); 20 Jan 2006 13:56:55 -0000 X-Spam-Check-By: sourceware.org Original-Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Jan 2006 13:56:54 +0000 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-64-251.inter.net.il [80.230.64.251]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DKD86224 (AUTH halo1); Fri, 20 Jan 2006 15:56:43 +0200 (IST) Original-To: cygwin@cygwin.com In-reply-to: (message from Igor Peshansky on Fri, 20 Jan 2006 08:29:20 -0500 (EST)) 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:73977 gmane.emacs.devel:49316 Archived-At: > Date: Fri, 20 Jan 2006 08:29:20 -0500 (EST) > From: Igor Peshansky > cc: djh , emacs-devel@gnu.org, cygwin@cygwin.com > > > > This break emac's dired.c (from compiling) > > > Ref: http://www.cygwin.com/ml/cygwin/2005-12/msg00205.html > > > > Without knowing the full details, I'd risk saying that this was not > > the best decision. Is there really no way of making d_ino be > > consistent with what `stat' returns about the same directory? > > Corinna already covered that. Where? I don't see anything from Corinna in the thread that followed the above message. (I don't read the Cygwin list.) > 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? My experience is the other way around: that d_ino is rarely used. > 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. > If the content of d_ino isn't required to be anything specific, a simpler > solution could be something like > > #ifdef __CYGWIN__ > #define d_ino __deprecated_d_ino > #endif It's bad mantra for an application to use a symbol that starts with "__", since those symbols are reserved for the library implementation. > 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.