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

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

quoted

quoted

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

quoted

quoted

quoted

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?

quoted

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