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, 22:08 UTC
Message-ID: <20060119220843.GA3601@steel.home>
In-Reply-To: <20060119183143.GB27888@trixie.casa.cgf.cx>

Christopher Faylor, Thu, Jan 19, 2006 19:31:43 +0100:

Show 12 quoted lines

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

Show 18 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 (!)
> 
> 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?

Show 13 quoted lines

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

Show 5 quoted lines

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