From: Eli Zaretskii <eliz@gnu.org>
Cc: henman@it.to-be.co.jp, emacs-devel@gnu.org
Subject: Re: New platform independent problem
Date: Fri, 20 Jan 2006 15:56:49 +0200 [thread overview]
Message-ID: <uoe27q9y6.fsf@gnu.org> (raw)
In-Reply-To: <Pine.GSO.4.63.0601200821540.17119@access1.cims.nyu.edu> (message from Igor Peshansky on Fri, 20 Jan 2006 08:29:20 -0500 (EST))
> Date: Fri, 20 Jan 2006 08:29:20 -0500 (EST)
> From: Igor Peshansky <pechtcha@cs.nyu.edu>
> cc: djh <henman@it.to-be.co.jp>, 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.
next prev parent reply other threads:[~2006-01-20 13:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-20 5:47 New platform independent problem djh
2006-01-20 11:08 ` Eli Zaretskii
2006-01-20 12:25 ` Corinna Vinschen
2006-01-20 13:59 ` Eric Blake
2006-01-20 14:14 ` Corinna Vinschen
2006-01-20 13:29 ` Igor Peshansky
2006-01-20 13:56 ` Eli Zaretskii [this message]
2006-01-20 14:18 ` Eric Blake
2006-01-20 16:48 ` Eli Zaretskii
2006-01-20 21:24 ` Andreas Schwab
2006-01-20 14:21 ` Corinna Vinschen
2006-01-27 20:45 ` Eli Zaretskii
2006-02-23 9:20 ` djh
-- strict thread matches above, loose matches on Subject: below --
2006-01-20 17:01 Eric Blake
2006-01-20 17:22 ` Eli Zaretskii
2006-01-28 14:18 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=uoe27q9y6.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=henman@it.to-be.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).