Re: New platform independent problem

[Eli Zaretskii]

> Date: Fri, 20 Jan 2006 07:18:18 -0700
> From: Eric Blake <address@hidden>
> CC: address@hidden,  address@hidden,  address@hidden
> 
> 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.

You could have a flag that, if set, will instruct readdir to do the
expensive processing.  Applications that need the real inode will set
that flag.

> > 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.

That may be so, but I don't think I've seen packages that check
whether d_ino exist in their configury.  They assume it does, AFAICS.

> > 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.

I was responding to a suggestion to use __deprecated_d_ino in the
Emacs code.  Emacs is certainly _not_ a part of implementation.

> What platforms use d_ino==0 to mean an empty entry, rather than an entry
> where st_ino must be checked?

I see it in Emacs, Corinna shows another example from rcp and scp.