Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jan 19, 2006, 10:42 UTC
Message-ID: <81b0412b0601190242m4792e73bg181172e478b6e0c2@mail.gmail.com>
In-Reply-To: <20060119052914.GC8121@trixie.casa.cgf.cx>

On 1/19/06, Christopher Faylor <me@cgf.cx> wrote:

> "They" probably don't like it when people treat an open source project as
> if it was some unresponsive proprietary enterprise which does not listen
> to or accept patches.

Please, accept my appologies for the sarcasm in the original post. Sometimes I get an impression of cygwin being not maintained at all, and that, if not justifies my behavior, but at least is an attempt to explain it.

Show 11 quoted lines

> >And on top of that, they removed dirent->d_ino (or probably replaced it
> >by __ino32, if at all).  BTW, can we somehow avoid using d_ino?  It is
> >referenced only in fsck-objects.c Anyway, to workaround this I put
> >
> >COMPAT_CFLAGS += -Dd_ino=__ino32
> >
> >It helps, but surely is not the solution.
>
> I don't see how it could help since __ino32 is not actually filled in
> with anything.  In fact, I'll rename the field to __invalid_ino32 to
> make that clear.

But why keep the DT_-macros?! And why there is two fields hinting at d_ino, and why there is 3 (!) "struct dirent" definitions in dirent.h (sys/dirent.h)? Some with different names (d_reserved?). And if cygwin is aiming for posix, what would d_fd or d_version be (Open Group Specs v6[1] mention only d_ino and d_name)?

[1] http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html