Mail Archives: cygwin/2006/01/20/08:57:00
> Date: Fri, 20 Jan 2006 08:29:20 -0500 (EST)
> From: Igor Peshansky <pechtcha AT cs DOT nyu DOT edu>
> cc: djh <henman AT it DOT to-be DOT co DOT jp>, emacs-devel AT gnu DOT org, cygwin AT cygwin DOT 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.
--
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/
- Raw text -