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

From: Junio C Hamano <junkio@cox.net>
Date: Jan 19, 2006, 08:59 UTC
Message-ID: <7vlkxciodu.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060119052914.GC8121@trixie.casa.cgf.cx>

Christopher Faylor <me@cgf.cx> writes:

> "They" probably would like to hear about any irregularities that are found.
> "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.

First of all, thanks for joining our discussion. Being able to hear from somebody from other project firsthand (not just listen to somebody talking in his own changelogs and code comments, but in actual e-mail exchange discussion) lets us put faces and names to the entity "so far just one of the external projects to us".

>>For reasons unknown, cygwin decided to use our sockaddr_storage.

I haven't looked at the proposed patch by Alex, so would not comment on this part, but I'd appreciate your input.

>>For the other, probably unrelated, reasons, they decided to leave
>>declarations of DT_* macros in dirent.h without providing dirent->d_type.

I was wondering what the justification for keeping DT_* without d_type myself. What is the preferred resolution on this one from your point of view? I suspect removing d_type while leaving DT_* was just a transient error and you would want to remove DT_* as well, in which case the patch on this issue by Alex would become unnecessary.

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.

I think renaming __invalid_* makes sense. I'll see how we would work this around on the git side to make things more portable.