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

[Alex Riesen <raa.lkml@gmail.com>]

Christopher Faylor, Thu, Jan 19, 2006 19:31:43 +0100:
> >>"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.
> 
> Hmm.  I thought we'd already dispelled the myth that cygwin is
> unsupported in this very mailing list.  That is an odd impression given
> the fact that you were complaining about behavior in a version of cygwin
> which was released on Monday but, apology accepted.

It was my first update since a long time (which BTW broke some
programs like cp: they missed symbols in cygwin1.dll).

> If you want to see evidence of continual cygwin development, you can always
> visit this page:  http://cygwin.com/snapshots/ .  This page has snapshots
> of cygwin built from cvs.  We make these available so that people will check
> things out prior to an actual release.

Thanks.

> >>>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 (!)
> 
> The default entry (i.e., the one you get without defining
> __INSIDE_CYGWIN__ or __CYGWIN_USE_BIG_TYPES__) in dirent.h is the
> correct one.

Maybe it'd be a good idea just to remove the definitions? Or, as
__INSIDE_CYGWIN__ implies, move them into cygwin internal sources.
Would be less confusion and no chance of someone defining one of the
macros and getting a binary-incompatible object?

> >"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
> 
> Hmm.  On linux, my /usr/include/bits/dirent.h has a d_reclen field in
> dirent.  I know what that is and what it is used for but it's not
> mentioned, that I can see, in SUSv3.  But, since I don't see anything in
> the description of dirent in SUSv3 which says that the must have only
> the fields mentiond, that's ok.

Of course, you don't have to. It all about making an impression

> In any event, we don't claim to be POSIX compatible.  We actually are
> working for linux compatibility but this is one regrettable place where
> Windows doesn't allow that.

The word was "aiming"

> Anyway, I understand why the DT macros would cause problems and I have
> removed them from the current CVS.  I don't see why the existence of
> extra fields in dirent or why other non-default definitions would
> cause any problems other than the "Doctor, doctor, it hurts when I
> do this" variety.

It is not the existance of the extra fields which cause problems. It
is an existance of fields, the names of which imply a functionality
they do not provide which causes problems. Why should I seeing __ino32
in an official header think: "it is never filled anyway, so I
shouldn't use it"?! Or what could "__invalid_d_ino" mean? If it is
invalid (as in "can't be used", why is it there at all?