{"thread":{"id":"3094","subject":"cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","startedAt":"2006-01-18T13:47:00Z","lastAt":"2006-01-23T13:07:18Z","messageCount":27,"participants":["Alex Riesen","Christopher Faylor","Junio C Hamano","Petr Baudis","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14809","messageId":"81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com","threadId":"3094","inReplyTo":null,"subject":"cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-18T13:47:00Z","receivedAt":"2006-01-18T13:47:00Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"For reasons unknown, cygwin decided to use our sockaddr_storage.\nAs it is redefined to sockaddr_in it'd cause compilation errors in\ncygwin headers. Fixed by first patch, which uses a more git-related\nname (can we claim rights for the symbol, being first to use it? :-)\n\nFor the other, probably unrelated, reasons, they decided to leave\ndeclarations of DT_* macros in dirent.h without providing dirent->d_type.\nThis is what NO_DTYPE in the 0002-patch is all about.\n\nAnd on top of that, they removed dirent->d_ino (or probably replaced\nit by __ino32, if at all).\nBTW, can we somehow avoid using d_ino? It is referenced only in fsck-objects.c\nAnyway, to workaround this I put\n\n  COMPAT_CFLAGS += -Dd_ino=__ino32\n\nIt helps, but surely is not the solution.\n\nP.S. For all you poor souls on Win2k, my config.mak contains:\n\n  NO_MMAP = YesPlease\n  NO_DTYPE = YesPlease\n  COMPAT_CFLAGS += -Dd_ino=__ino32\n\nJust to make it work (at least it's enough for me, even the tests run...)\n\n\n>From nobody Mon Sep 17 00:00:00 2001\nFrom: Alex Riesen <raa.lkml@gmail.com>\nDate: Wed Jan 18 14:02:54 2006 +0100\nSubject: fix compilation of sockaddr_storage\n\n---\n\n Makefile |    2 +-\n daemon.c |    4 ++--\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\n59379c380a6c2829c5614aadd4a5492abb8d14c8\ndiff --git a/Makefile b/Makefile\nindex f6d9e0a..5782e2a 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -342,7 +342,7 @@ ifdef NO_MMAP\n \tCOMPAT_OBJS += compat/mmap.o\n endif\n ifdef NO_IPV6\n-\tALL_CFLAGS += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in\n+\tALL_CFLAGS += -DNO_IPV6 -Dsockaddr_stg_git=sockaddr_in\n endif\n \n ifdef PPC_SHA1\ndiff --git a/daemon.c b/daemon.c\nindex bb014fa..b424e5e 100644\n--- a/daemon.c\n+++ b/daemon.c\n@@ -277,7 +277,7 @@ static unsigned int children_deleted = 0\n static struct child {\n \tpid_t pid;\n \tint addrlen;\n-\tstruct sockaddr_storage address;\n+\tstruct sockaddr_stg_git address;\n } live_child[MAX_CHILDREN];\n \n static void add_child(int idx, pid_t pid, struct sockaddr *addr, int addrlen)\n@@ -578,7 +578,7 @@ static int service_loop(int socknum, int\n \n \t\tfor (i = 0; i < socknum; i++) {\n \t\t\tif (pfd[i].revents & POLLIN) {\n-\t\t\t\tstruct sockaddr_storage ss;\n+\t\t\t\tstruct sockaddr_stg_git ss;\n \t\t\t\tunsigned int sslen = sizeof(ss);\n \t\t\t\tint incoming = accept(pfd[i].fd, (struct sockaddr *)&ss, &sslen);\n \t\t\t\tif (incoming < 0) {\n-- \n1.1.2-ge577\n\n\n\n\n\n>From nobody Mon Sep 17 00:00:00 2001\nFrom: Alex Riesen <raa.lkml@gmail.com>\nDate: Wed Jan 18 14:04:34 2006 +0100\nSubject: fix compilation of dirent->d_type\n\n---\n\n Makefile |    3 +++\n cache.h  |   10 +++++++++-\n 2 files changed, 12 insertions(+), 1 deletions(-)\n\n5232f9128ad9d10368525fe709954acc2d6f49b3\ndiff --git a/Makefile b/Makefile\nindex 5782e2a..c3bae0f 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -329,6 +329,9 @@ ifdef NEEDS_NSL\n \tLIBS += -lnsl\n \tSIMPLE_LIB += -lnsl\n endif\n+ifdef NO_DTYPE\n+\tCOMPAT_CFLAGS += -DNO_DTYPE\n+endif\n ifdef NO_STRCASESTR\n \tCOMPAT_CFLAGS += -DNO_STRCASESTR\n \tCOMPAT_OBJS += compat/strcasestr.o\ndiff --git a/cache.h b/cache.h\nindex 29c9e81..3846fb9 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -10,13 +10,21 @@\n #define deflateBound(c,s)  ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)\n #endif\n \n-#ifdef DT_UNKNOWN\n+#ifndef NO_DTYPE\n #define DTYPE(de)\t((de)->d_type)\n #else\n+#ifndef DT_UNKNOWN\n #define DT_UNKNOWN\t0\n+#endif\n+#ifndef DT_DIR\n #define DT_DIR\t\t1\n+#endif\n+#ifndef DT_REG\n #define DT_REG\t\t2\n+#endif\n+#ifndef DT_LNK\n #define DT_LNK\t\t3\n+#endif\n #define DTYPE(de)\tDT_UNKNOWN\n #endif\n \n-- \n1.1.2-ge577\n\n\n"},{"id":"14875","messageId":"20060119052914.GC8121@trixie.casa.cgf.cx","threadId":"3094","inReplyTo":"81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T05:29:14Z","receivedAt":"2006-01-19T05:29:14Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Wed, Jan 18, 2006 at 02:47:00PM +0100, Alex Riesen wrote:\n>For reasons unknown, cygwin decided to use our sockaddr_storage.\n>As it is redefined to sockaddr_in it'd cause compilation errors in\n>cygwin headers. Fixed by first patch, which uses a more git-related\n>name (can we claim rights for the symbol, being first to use it? :-)\n>\n>For the other, probably unrelated, reasons, they decided to leave\n>declarations of DT_* macros in dirent.h without providing dirent->d_type.\n>This is what NO_DTYPE in the 0002-patch is all about.\n\n\"They\" probably would like to hear about any irregularities that are found.\n\"They\" probably don't like it when people treat an open source project as\nif it was some unresponsive proprietary enterprise which does not listen\nto or accept patches.\n\n>And on top of that, they removed dirent->d_ino (or probably replaced it\n>by __ino32, if at all).  BTW, can we somehow avoid using d_ino?  It is\n>referenced only in fsck-objects.c Anyway, to workaround this I put\n>\n>COMPAT_CFLAGS += -Dd_ino=__ino32\n>\n>It helps, but surely is not the solution.\n\nI don't see how it could help since __ino32 is not actually filled in\nwith anything.  In fact, I'll rename the field to __invalid_ino32 to\nmake that clear.\n\ncgf\n(cygwin project lead)\n"},{"id":"14878","messageId":"7vlkxciodu.fsf@assigned-by-dhcp.cox.net","threadId":"3094","inReplyTo":"20060119052914.GC8121@trixie.casa.cgf.cx","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-19T08:59:57Z","receivedAt":"2006-01-19T08:59:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christopher Faylor <me@cgf.cx> writes:\n\n> \"They\" probably would like to hear about any irregularities that are found.\n> \"They\" probably don't like it when people treat an open source project as\n> if it was some unresponsive proprietary enterprise which does not listen\n> to or accept patches.\n\nFirst of all, thanks for joining our discussion.  Being able to\nhear from somebody from other project firsthand (not just listen\nto somebody talking in his own changelogs and code comments, but\nin actual e-mail exchange discussion) lets us put faces and\nnames to the entity \"so far just one of the external projects to\nus\".\n\n>>For reasons unknown, cygwin decided to use our sockaddr_storage.\n\nI haven't looked at the proposed patch by Alex, so would not\ncomment on this part, but I'd appreciate your input.\n\n>>For the other, probably unrelated, reasons, they decided to leave\n>>declarations of DT_* macros in dirent.h without providing dirent->d_type.\n\nI was wondering what the justification for keeping DT_* without\nd_type myself.  What is the preferred resolution on this one\nfrom your point of view?  I suspect removing d_type while\nleaving DT_* was just a transient error and you would want to\nremove DT_* as well, in which case the patch on this issue by\nAlex would become unnecessary.\n\n>>And on top of that, they removed dirent->d_ino (or probably replaced it\n>>by __ino32, if at all).  BTW, can we somehow avoid using d_ino?  It is\n>>referenced only in fsck-objects.c Anyway, to workaround this I put\n>>\n>>COMPAT_CFLAGS += -Dd_ino=__ino32\n>>\n>>It helps, but surely is not the solution.\n>\n> I don't see how it could help since __ino32 is not actually filled in\n> with anything.  In fact, I'll rename the field to __invalid_ino32 to\n> make that clear.\n\nI think renaming __invalid_* makes sense.  I'll see how we would\nwork this around on the git side to make things more portable.\n"},{"id":"14882","messageId":"81b0412b0601190242m4792e73bg181172e478b6e0c2@mail.gmail.com","threadId":"3094","inReplyTo":"20060119052914.GC8121@trixie.casa.cgf.cx","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-19T10:42:46Z","receivedAt":"2006-01-19T10:42:46Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/19/06, Christopher Faylor <me@cgf.cx> wrote:\n> \"They\" probably don't like it when people treat an open source project as\n> if it was some unresponsive proprietary enterprise which does not listen\n> to or accept patches.\n\nPlease, accept my appologies for the sarcasm in the original post.\nSometimes I get an impression of cygwin being not maintained at\nall, and that, if not justifies my behavior, but at least is an attempt\nto explain it.\n\n> >And on top of that, they removed dirent->d_ino (or probably replaced it\n> >by __ino32, if at all).  BTW, can we somehow avoid using d_ino?  It is\n> >referenced only in fsck-objects.c Anyway, to workaround this I put\n> >\n> >COMPAT_CFLAGS += -Dd_ino=__ino32\n> >\n> >It helps, but surely is not the solution.\n>\n> I don't see how it could help since __ino32 is not actually filled in\n> with anything.  In fact, I'll rename the field to __invalid_ino32 to\n> make that clear.\n\nBut why keep the DT_-macros?! And why there is two fields\nhinting at d_ino, and why there is 3 (!) \"struct dirent\"\ndefinitions in dirent.h (sys/dirent.h)?\nSome with different names (d_reserved?).\nAnd if cygwin is aiming for posix, what would d_fd or d_version\nbe (Open Group Specs v6[1] mention only d_ino and d_name)?\n\n[1] http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html\n"},{"id":"14888","messageId":"20060119125155.GZ28365@pasky.or.cz","threadId":"3094","inReplyTo":"81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-01-19T12:51:55Z","receivedAt":"2006-01-19T12:51:55Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Jan 18, 2006 at 02:47:00PM CET, I got a letter\nwhere Alex Riesen <raa.lkml@gmail.com> said that...\n> For reasons unknown, cygwin decided to use our sockaddr_storage.\n> As it is redefined to sockaddr_in it'd cause compilation errors in\n> cygwin headers. Fixed by first patch, which uses a more git-related\n> name (can we claim rights for the symbol, being first to use it? :-)\n\nHuh? \"Our\"? See RFC 2553 and e.g.:\n\n\thttp://www.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html\n\nYou have no business meddling with this identifier except working around\nplatforms which do not support it, but then do not complain that things\nbreak when the platforms actually start supporting it. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe.  -- Douglas Adams\n"},{"id":"14889","messageId":"20060119130009.GA28365@pasky.or.cz","threadId":"3094","inReplyTo":"81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-01-19T13:00:09Z","receivedAt":"2006-01-19T13:00:09Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"I actually forgot to look at the patch.\n\nDear diary, on Wed, Jan 18, 2006 at 02:47:00PM CET, I got a letter\nwhere Alex Riesen <raa.lkml@gmail.com> said that...\n>  Makefile |    2 +-\n>  daemon.c |    4 ++--\n>  2 files changed, 3 insertions(+), 3 deletions(-)\n> \n> 59379c380a6c2829c5614aadd4a5492abb8d14c8\n> diff --git a/Makefile b/Makefile\n> index f6d9e0a..5782e2a 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -342,7 +342,7 @@ ifdef NO_MMAP\n>  \tCOMPAT_OBJS += compat/mmap.o\n>  endif\n>  ifdef NO_IPV6\n> -\tALL_CFLAGS += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in\n> +\tALL_CFLAGS += -DNO_IPV6 -Dsockaddr_stg_git=sockaddr_in\n\n  +else\n  +\tALL_CFLAGS += -Dsockaddr_stg_git=sockaddr_storage\n\n>  endif\n>  \n>  ifdef PPC_SHA1\n\n  But of course when this goes on, soon the gcc commandline will get\nreally awfully ugly. This is why something _like_ autoconf is a good\nthing - you can just detect if the system headers provide the type and\n#define it only when they don't.\n\n  Of course, inserting the #define to some .h file might work; I'm not\nsure if any of the relevant socket routines is permitted to be a macro\nwhich could expand to something - but even then, it's probably not very\nlikely that it would break stuff in practice.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe.  -- Douglas Adams\n"},{"id":"14897","messageId":"81b0412b0601190704j617205c4g8a66a55638b5a6c4@mail.gmail.com","threadId":"3094","inReplyTo":"20060119125155.GZ28365@pasky.or.cz","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-19T15:04:26Z","receivedAt":"2006-01-19T15:04:26Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/19/06, Petr Baudis <pasky@suse.cz> wrote:\n> Dear diary, on Wed, Jan 18, 2006 at 02:47:00PM CET, I got a letter\n> where Alex Riesen <raa.lkml@gmail.com> said that...\n> > For reasons unknown, cygwin decided to use our sockaddr_storage.\n> > As it is redefined to sockaddr_in it'd cause compilation errors in\n> > cygwin headers. Fixed by first patch, which uses a more git-related\n> > name (can we claim rights for the symbol, being first to use it? :-)\n>\n> Huh? \"Our\"? See RFC 2553 and e.g.:\n>\n>         http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html\n>\n> You have no business meddling with this identifier except working around\n> platforms which do not support it, but then do not complain that things\n> break when the platforms actually start supporting it. ;-)\n\nThat will remind me to consult the specs first.\n"},{"id":"14898","messageId":"81b0412b0601190707g5613a755l7457d8b76039c0ea@mail.gmail.com","threadId":"3094","inReplyTo":"20060119130009.GA28365@pasky.or.cz","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-19T15:07:49Z","receivedAt":"2006-01-19T15:07:49Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/19/06, Petr Baudis <pasky@suse.cz> wrote:\n>   But of course when this goes on, soon the gcc commandline will get\n> really awfully ugly. This is why something _like_ autoconf is a good\n> thing - you can just detect if the system headers provide the type and\n> #define it only when they don't.\n\nnot you. Someone has done the job of detecting things for you.\nIt's just a fair amount of hard work badly done.\n"},{"id":"14899","messageId":"20060119161000.GA27888@trixie.casa.cgf.cx","threadId":"3094","inReplyTo":"7vlkxciodu.fsf@assigned-by-dhcp.cox.net","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T16:10:00Z","receivedAt":"2006-01-19T16:10:00Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jan 19, 2006 at 12:59:57AM -0800, Junio C Hamano wrote:\n>Christopher Faylor <me@cgf.cx> writes:\n>>\"They\" probably would like to hear about any irregularities that are\n>>found.  \"They\" probably don't like it when people treat an open source\n>>project as if it was some unresponsive proprietary enterprise which\n>>does not listen to or accept patches.\n>\n>First of all, thanks for joining our discussion.\n\nYou're welcome.  I use git on linux and cygwin so I'm happy to try to help.\n\n>Being able to hear from somebody from other project firsthand (not just\n>listen to somebody talking in his own changelogs and code comments, but\n>in actual e-mail exchange discussion) lets us put faces and names to\n>the entity \"so far just one of the external projects to us\".\n\nI only read this list sporadically but I have chimed in from time to time\nwhen people were talking about cygwin.  For the most part, it seems like\nmy input hasn't been needed all that much.\n\n>>>For reasons unknown, cygwin decided to use our sockaddr_storage.\n>\n>I haven't looked at the proposed patch by Alex, so would not comment on\n>this part, but I'd appreciate your input.\n>\n>>>For the other, probably unrelated, reasons, they decided to leave\n>>>declarations of DT_* macros in dirent.h without providing\n>>>dirent->d_type.\n>\n>I was wondering what the justification for keeping DT_* without d_type\n>myself.  What is the preferred resolution on this one from your point\n>of view?  I suspect removing d_type while leaving DT_* was just a\n>transient error and you would want to remove DT_* as well, in which\n>case the patch on this issue by Alex would become unnecessary.\n\nActually, I started adding DT_* macros at one point, in preparation for\nadding d_type, and then got sidetracked.  Their existence is a real bug\nso, I have ifdef'ed out the DT macros in current CVS.\n\n>>>And on top of that, they removed dirent->d_ino (or probably replaced it\n>>>by __ino32, if at all).  BTW, can we somehow avoid using d_ino?  It is\n>>>referenced only in fsck-objects.c Anyway, to workaround this I put\n>>>\n>>>COMPAT_CFLAGS += -Dd_ino=__ino32\n>>>\n>>>It helps, but surely is not the solution.\n>>\n>> I don't see how it could help since __ino32 is not actually filled in\n>> with anything.  In fact, I'll rename the field to __invalid_ino32 to\n>> make that clear.\n>\n>I think renaming __invalid_* makes sense.  I'll see how we would\n>work this around on the git side to make things more portable.\n\nThere were two fields in the dirent struct.  One was the \"real\" d_ino\nwhich was a 64-bit ino_t, __ino32 was a legacy field from a time when\ninodes were 32 bits.  I had already renamed the d_ino to __invalid_d_ino\nbut I didn't think I had to rename __ino32, too, since it wasn't a\nstandard field and didn't think that anyone would be using it.  However,\nit is now __invalid_ino32 (and will probably disappear entirely) in CVS.\n\nI knew that there would be fallout from getting rid of d_ino but this\nchange has been a long time coming.  Previously, the inodes reported in\nd_ino were different from the (correct) ones in st_ino and some\napplications were understandbly confused by that fact.  Making d_ino\naccurate would have meant that we'd have to open every file in readdir\nto get the windows equivalent of inode information and, since we get\nenough \"cygwin is slow\" complaints, that wasn't a cost we were willing\nto pay.\n\ncgf\n"},{"id":"14913","messageId":"20060119183143.GB27888@trixie.casa.cgf.cx","threadId":"3094","inReplyTo":"81b0412b0601190242m4792e73bg181172e478b6e0c2@mail.gmail.com","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T18:31:43Z","receivedAt":"2006-01-19T18:31:43Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jan 19, 2006 at 11:42:46AM +0100, Alex Riesen wrote:\n>On 1/19/06, Christopher Faylor <me@cgf.cx> wrote:\n>>\"They\" probably don't like it when people treat an open source project\n>>as if it was some unresponsive proprietary enterprise which does not\n>>listen to or accept patches.\n>\n>Please, accept my appologies for the sarcasm in the original post.\n>Sometimes I get an impression of cygwin being not maintained at all,\n>and that, if not justifies my behavior, but at least is an attempt to\n>explain it.\n\nHmm.  I thought we'd already dispelled the myth that cygwin is\nunsupported in this very mailing list.  That is an odd impression given\nthe fact that you were complaining about behavior in a version of cygwin\nwhich was released on Monday but, apology accepted.\n\nIf you want to see evidence of continual cygwin development, you can always\nvisit this page:  http://cygwin.com/snapshots/ .  This page has snapshots\nof cygwin built from cvs.  We make these available so that people will check\nthings out prior to an actual release.\n\n>>>And on top of that, they removed dirent->d_ino (or probably replaced it\n>>>by __ino32, if at all).  BTW, can we somehow avoid using d_ino?  It is\n>>>referenced only in fsck-objects.c Anyway, to workaround this I put\n>>>\n>>>COMPAT_CFLAGS += -Dd_ino=__ino32\n>>>\n>>>It helps, but surely is not the solution.\n>>\n>>I don't see how it could help since __ino32 is not actually filled in\n>>with anything.  In fact, I'll rename the field to __invalid_ino32 to\n>>make that clear.\n>\n>But why keep the DT_-macros?! And why there is two fields hinting at\n>d_ino, and why there is 3 (!)\n\nThe default entry (i.e., the one you get without defining\n__INSIDE_CYGWIN__ or __CYGWIN_USE_BIG_TYPES__) in dirent.h is the\ncorrect one.\n\n>\"struct dirent\" definitions in dirent.h (sys/dirent.h)?  Some with\n>different names (d_reserved?).  And if cygwin is aiming for posix, what\n>would d_fd or d_version be (Open Group Specs v6[1] mention only d_ino\n>and d_name)?\n>\n>[1]\n>http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html\n\nHmm.  On linux, my /usr/include/bits/dirent.h has a d_reclen field in\ndirent.  I know what that is and what it is used for but it's not\nmentioned, that I can see, in SUSv3.  But, since I don't see anything in\nthe description of dirent in SUSv3 which says that the must have only\nthe fields mentiond, that's ok.\n\nIn any event, we don't claim to be POSIX compatible.  We actually are\nworking for linux compatibility but this is one regrettable place where\nWindows doesn't allow that.\n\nI explained about the DT macros and why we dropped d_ino support in\nanother message.\n\nAnyway, I understand why the DT macros would cause problems and I have\nremoved them from the current CVS.  I don't see why the existence of\nextra fields in dirent or why other non-default definitions would\ncause any problems other than the \"Doctor, doctor, it hurts when I\ndo this\" variety.\n\ncgf\n"},{"id":"14916","messageId":"20060119203428.GA5090@trixie.casa.cgf.cx","threadId":"3094","inReplyTo":"20060119161000.GA27888@trixie.casa.cgf.cx","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T20:34:28Z","receivedAt":"2006-01-19T20:34:28Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jan 19, 2006 at 11:10:00AM -0500, Christopher Faylor wrote:\n>On Thu, Jan 19, 2006 at 12:59:57AM -0800, Junio C Hamano wrote:\n>>Christopher Faylor <me@cgf.cx> writes:\n>>>\"They\" probably would like to hear about any irregularities that are\n>>>found.  \"They\" probably don't like it when people treat an open source\n>>>project as if it was some unresponsive proprietary enterprise which\n>>>does not listen to or accept patches.\n>>\n>>First of all, thanks for joining our discussion.\n>\n>You're welcome.  I use git on linux and cygwin so I'm happy to try to help.\n\nBtw, we're looking to roll out a new release of cygwin which fixes the\nembarrassing typo in sockaddr_storage.  It is fixed in cygwin snapshots:\n\nhttp://cygwin.com/snapshots/\n\ncgf\n"},{"id":"14918","messageId":"Pine.LNX.4.64.0601191309130.3240@g5.osdl.org","threadId":"3094","inReplyTo":"20060119203428.GA5090@trixie.casa.cgf.cx","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-19T21:16:17Z","receivedAt":"2006-01-19T21:16:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 19 Jan 2006, Christopher Faylor wrote:\n> \n> Btw, we're looking to roll out a new release of cygwin which fixes the\n> embarrassing typo in sockaddr_storage.  It is fixed in cygwin snapshots:\n> \n> http://cygwin.com/snapshots/\n\nQuick question for cygwin people (I asked this at an earlier point, but I \ndon't think there was any reply): would cygwin prefer using \"vfork()\" over \n\"fork()\", or is there no advantage? With vfork(), I could imagine that you \nmight avoid a lot of strange VM games.. \n\nI think almost all of the git fork usage is of the type where \"vfork()\" \nwould work fine (git-daemon in non-inetd form is an exception, perhaps the \nonly one).\n\nSo if using vfork() is preferable, we probably should do that. It tends to \nbe a small performance improvement on Linux too, although on Linux it's \nreally pretty much in the noise.\n\nAlternatively, is there anything else we can do that makes things easier?\n\n\t\t\tLinus\n"},{"id":"14920","messageId":"20060119212856.GA6317@trixie.casa.cgf.cx","threadId":"3094","inReplyTo":"Pine.LNX.4.64.0601191309130.3240@g5.osdl.org","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T21:28:56Z","receivedAt":"2006-01-19T21:28:56Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jan 19, 2006 at 01:16:17PM -0800, Linus Torvalds wrote:\n>On Thu, 19 Jan 2006, Christopher Faylor wrote:\n>>Btw, we're looking to roll out a new release of cygwin which fixes the\n>>embarrassing typo in sockaddr_storage.  It is fixed in cygwin\n>>snapshots:\n>>\n>>http://cygwin.com/snapshots/\n>\n>Quick question for cygwin people (I asked this at an earlier point, but\n>I don't think there was any reply): would cygwin prefer using \"vfork()\"\n>over \"fork()\", or is there no advantage?  With vfork(), I could imagine\n>that you might avoid a lot of strange VM games..\n\nSorry, I missed the earlier question.  I have to get in the habit of\nscanning this list more regularly for this type of thing.\n\nCygwin's vfork implementation currently defaults to fork so it doesn't\nmatter which is used.\n\nWe used to have a vfork which tried to cut down on some of the\nsubstantial overhead that comes with cygwin's fork() but the vfork\nimplementation eventually grew so complicated that there was eventually\nno performance gain and I decided to just yank it and revisit it at\na later point.\n\nSo, for now, there is no difference, but, eventually, there might be if\nsomeone masters courage to revisit vfork-on-cygwin.\n\nSo, I guess that means that it would be a good idea to switch to vfork\nif you were planning for the nebulous future when this made a difference\nto cygwin.  Otherwise, I wouldn't bother.\n\n>Alternatively, is there anything else we can do that makes things easier?\n\nI'm really committed to making cygwin as much like linux as possible so\nthat you won't have to make things easier.  The last release added some\nstuff which should make building linux easier, in fact.  Also, the\nmmap() implementation should be a littler closer to linux.  It is, of\ncourse, a work in progress, though.\n\nThe only thing that would speed up process creation in cygwin now is\nthe use of the windows spawn* family of function calls.  Those could be\nused instead of fork/exec but I have a personal aversion to using them\nsince they are so non-UNIX.  If performance is an issue, however, that\ncould be something to investigate.\n\ncgf\n"},{"id":"14922","messageId":"Pine.LNX.4.64.0601191334390.3240@g5.osdl.org","threadId":"3094","inReplyTo":"20060119212856.GA6317@trixie.casa.cgf.cx","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-01-19T21:44:58Z","receivedAt":"2006-01-19T21:44:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 19 Jan 2006, Christopher Faylor wrote:\n> \n> The only thing that would speed up process creation in cygwin now is\n> the use of the windows spawn* family of function calls.  Those could be\n> used instead of fork/exec but I have a personal aversion to using them\n> since they are so non-UNIX.  If performance is an issue, however, that\n> could be something to investigate.\n\nWhat about posix_spawn()? I don't know the windows spawn things, but I \nassume posix_spawn() is basically trying to be them.. Does it work with \ncygwin if we try to convert some of the more obvious users?\n\nSome of the git users should be easy to convert to posix_spawn()..\n\n\t\tLinus\n"},{"id":"14923","messageId":"20060119215146.GC5090@trixie.casa.cgf.cx","threadId":"3094","inReplyTo":"Pine.LNX.4.64.0601191334390.3240@g5.osdl.org","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T21:51:46Z","receivedAt":"2006-01-19T21:51:46Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jan 19, 2006 at 01:44:58PM -0800, Linus Torvalds wrote:\n>\n>On Thu, 19 Jan 2006, Christopher Faylor wrote:\n>> \n>> The only thing that would speed up process creation in cygwin now is\n>> the use of the windows spawn* family of function calls.  Those could be\n>> used instead of fork/exec but I have a personal aversion to using them\n>> since they are so non-UNIX.  If performance is an issue, however, that\n>> could be something to investigate.\n>\n>What about posix_spawn()? I don't know the windows spawn things, but I \n>assume posix_spawn() is basically trying to be them.. Does it work with \n>cygwin if we try to convert some of the more obvious users?\n\nYou know, I couldn't remember what the name of the spawn that was\nintroduced for posix.  I was going to mention it in my email and I\nforgot.  Obviously it was because the name so obscure that no one could\npossibly remember it.  :-)\n\nWe don't emulate posix_spawn currently but we could and should.  I'll\nput it on the todo list.\n\ncgf\n"},{"id":"14924","messageId":"20060119220843.GA3601@steel.home","threadId":"3094","inReplyTo":"20060119183143.GB27888@trixie.casa.cgf.cx","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-19T22:08:43Z","receivedAt":"2006-01-19T22:08:43Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Christopher Faylor, Thu, Jan 19, 2006 19:31:43 +0100:\n> >>\"They\" probably don't like it when people treat an open source project\n> >>as if it was some unresponsive proprietary enterprise which does not\n> >>listen to or accept patches.\n> >Please, accept my appologies for the sarcasm in the original post.\n> >Sometimes I get an impression of cygwin being not maintained at all,\n> >and that, if not justifies my behavior, but at least is an attempt to\n> >explain it.\n> \n> Hmm.  I thought we'd already dispelled the myth that cygwin is\n> unsupported in this very mailing list.  That is an odd impression given\n> the fact that you were complaining about behavior in a version of cygwin\n> which was released on Monday but, apology accepted.\n\nIt was my first update since a long time (which BTW broke some\nprograms like cp: they missed symbols in cygwin1.dll).\n\n> If you want to see evidence of continual cygwin development, you can always\n> visit this page:  http://cygwin.com/snapshots/ .  This page has snapshots\n> of cygwin built from cvs.  We make these available so that people will check\n> things out prior to an actual release.\n\nThanks.\n\n> >>>And on top of that, they removed dirent->d_ino (or probably replaced it\n> >>>by __ino32, if at all).  BTW, can we somehow avoid using d_ino?  It is\n> >>>referenced only in fsck-objects.c Anyway, to workaround this I put\n> >>>\n> >>>COMPAT_CFLAGS += -Dd_ino=__ino32\n> >>>\n> >>>It helps, but surely is not the solution.\n> >>\n> >>I don't see how it could help since __ino32 is not actually filled in\n> >>with anything.  In fact, I'll rename the field to __invalid_ino32 to\n> >>make that clear.\n> >\n> >But why keep the DT_-macros?! And why there is two fields hinting at\n> >d_ino, and why there is 3 (!)\n> \n> The default entry (i.e., the one you get without defining\n> __INSIDE_CYGWIN__ or __CYGWIN_USE_BIG_TYPES__) in dirent.h is the\n> correct one.\n\nMaybe it'd be a good idea just to remove the definitions? Or, as\n__INSIDE_CYGWIN__ implies, move them into cygwin internal sources.\nWould be less confusion and no chance of someone defining one of the\nmacros and getting a binary-incompatible object?\n\n> >\"struct dirent\" definitions in dirent.h (sys/dirent.h)?  Some with\n> >different names (d_reserved?).  And if cygwin is aiming for posix, what\n> >would d_fd or d_version be (Open Group Specs v6[1] mention only d_ino\n> >and d_name)?\n> >\n> >[1]\n> >http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html\n> \n> Hmm.  On linux, my /usr/include/bits/dirent.h has a d_reclen field in\n> dirent.  I know what that is and what it is used for but it's not\n> mentioned, that I can see, in SUSv3.  But, since I don't see anything in\n> the description of dirent in SUSv3 which says that the must have only\n> the fields mentiond, that's ok.\n\nOf course, you don't have to. It all about making an impression\n\n> In any event, we don't claim to be POSIX compatible.  We actually are\n> working for linux compatibility but this is one regrettable place where\n> Windows doesn't allow that.\n\nThe word was \"aiming\"\n\n> Anyway, I understand why the DT macros would cause problems and I have\n> removed them from the current CVS.  I don't see why the existence of\n> extra fields in dirent or why other non-default definitions would\n> cause any problems other than the \"Doctor, doctor, it hurts when I\n> do this\" variety.\n\nIt is not the existance of the extra fields which cause problems. It\nis an existance of fields, the names of which imply a functionality\nthey do not provide which causes problems. Why should I seeing __ino32\nin an official header think: \"it is never filled anyway, so I\nshouldn't use it\"?! Or what could \"__invalid_d_ino\" mean? If it is\ninvalid (as in \"can't be used\", why is it there at all?\n"},{"id":"14929","messageId":"20060119225128.GA8702@trixie.casa.cgf.cx","threadId":"3094","inReplyTo":"20060119220843.GA3601@steel.home","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T22:51:28Z","receivedAt":"2006-01-19T22:51:28Z","isPatch":false,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jan 19, 2006 at 11:08:43PM +0100, Alex Riesen wrote:\n>Christopher Faylor, Thu, Jan 19, 2006 19:31:43 +0100:\n>>Hmm.  I thought we'd already dispelled the myth that cygwin is\n>>unsupported in this very mailing list.  That is an odd impression given\n>>the fact that you were complaining about behavior in a version of\n>>cygwin which was released on Monday but, apology accepted.\n>\n>It was my first update since a long time (which BTW broke some programs\n>like cp: they missed symbols in cygwin1.dll).\n\nDetailed bug reports are always welcome on the cygwin mailing list:\ncygwin at cygwin dot com .  I should point out that the existence of\nbugs in a product does not indicate a lack of support of the product,\nhowever.\n\n>Maybe it'd be a good idea just to remove the definitions? Or, as\n>__INSIDE_CYGWIN__ implies, move them into cygwin internal sources.\n>Would be less confusion and no chance of someone defining one of the\n>macros and getting a binary-incompatible object?\n\nI sincerely doubt that anyone in this mailing list wants to get into a\ndiscussion of cygwin design.  If you really want to discuss this, the\ncygwin mailing list is a much better place for that.\n\ncgf\n"},{"id":"14933","messageId":"7vzmlr7lc3.fsf@assigned-by-dhcp.cox.net","threadId":"3094","inReplyTo":"81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-20T01:13:32Z","receivedAt":"2006-01-20T01:13:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> writes:\n\n> For reasons unknown, cygwin decided to use our sockaddr_storage.\n> As it is redefined to sockaddr_in it'd cause compilation errors in\n> cygwin headers.\n\nJust removing \"-Dsockaddr_storage=sockaddr_in\" from ALL_CFLAGS\nseems to solve the problem for new Cygwin.\n\nI doubt that -Dsockaddr_storage=sockaddr_in should be tied to\nNO_IPV6.  Maybe a better approach would be something like the\nattached patch.\n\nAlthough /usr/include/cygwin/in.h seems to have struct sockaddr_in6,\ngetaddrinfo() and friends still do not seem to be there, so\nNO_IPV6 still remains in effect on Cygwin.\n\nComments?\n\n-- >8 --\n[PATCH] Makefile: do not assume lack of IPV6 means no sockaddr_storage.\n\nNoticed first by Alex, that the latest Cygwin now properly has\nsockaddr_storage.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n Makefile |   12 +++++++++++-\n 1 files changed, 11 insertions(+), 1 deletions(-)\n\n0b61a10bb258ae0971bce3e01e40a5a9e5d9537f\ndiff --git a/Makefile b/Makefile\nindex f6d9e0a..e8f4b24 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -42,6 +42,9 @@ all:\n #\n # Define NO_IPV6 if you lack IPv6 support and getaddrinfo().\n #\n+# Define NO_SOCKADDR_STORAGE if your platform does not have struct\n+# sockaddr_storage.\n+#\n # Define COLLISION_CHECK below if you believe that SHA1's\n # 1461501637330902918203684832716283019655932542976 hashes do not give you\n # sufficient guarantee that no collisions between objects will ever happen.\n@@ -342,7 +345,14 @@ ifdef NO_MMAP\n \tCOMPAT_OBJS += compat/mmap.o\n endif\n ifdef NO_IPV6\n-\tALL_CFLAGS += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in\n+\tALL_CFLAGS += -DNO_IPV6\n+endif\n+ifdef NO_SOCKADDR_STORAGE\n+ifdef NO_IPV6\n+\tALL_CFLAGS += -Dsockaddr_storage=sockaddr_in\n+else\n+\tALL_CFLAGS += -Dsockaddr_storage=sockaddr_in6\n+endif\n endif\n \n ifdef PPC_SHA1\n-- \n1.1.3-gacdd\n"},{"id":"14936","messageId":"7vu0bz7lbk.fsf@assigned-by-dhcp.cox.net","threadId":"3094","inReplyTo":"7vlkxciodu.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] fsck-objects: support platforms without d_ino in struct dirent.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-20T01:13:51Z","receivedAt":"2006-01-20T01:13:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The d_ino field is only used for performance reasons in\nfsck-objects.  On a typical filesystem, i-number tends to have a\nstrong correlation with where the actual bits sit on the disk\nplatter, and we sort the entries to allow us scan things that\nought to be close together together.\n\nIf the platform lacks support for it, it is not a big deal.\nJust do not use d_ino for sorting, and scan them unsorted.\n\n---\n\n    Junio C Hamano <junkio@cox.net> writes:\n\n    > ...  I'll see how we would\n    > work this around on the git side to make things more portable.\n\n Makefile       |    6 ++++++\n fsck-objects.c |   13 +++++++++++--\n 2 files changed, 17 insertions(+), 2 deletions(-)\n\n4bec2123116a92fbeae12afc70317dfc85f6087b\ndiff --git a/Makefile b/Makefile\nindex e8f4b24..31898f7 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -19,6 +19,8 @@ all:\n # Define NO_EXPAT if you do not have expat installed.  git-http-push is\n # not built, and you cannot push using http:// and https:// transports.\n #\n+# Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.\n+#\n # Define NO_STRCASESTR if you don't have strcasestr.\n #\n # Define NO_SETENV if you don't have setenv in the C library.\n@@ -231,6 +233,7 @@ ifeq ($(uname_S),SunOS)\n \tALL_CFLAGS += -D__EXTENSIONS__\n endif\n ifeq ($(uname_O),Cygwin)\n+\tNO_D_INO_IN_DIRENT = YesPlease\n \tNO_STRCASESTR = YesPlease\n \tNEEDS_LIBICONV = YesPlease\n \t# There are conflicting reports about this.\n@@ -332,6 +335,9 @@ ifdef NEEDS_NSL\n \tLIBS += -lnsl\n \tSIMPLE_LIB += -lnsl\n endif\n+ifdef NO_D_INO_IN_DIRENT\n+\tALL_CFLAGS += -DNO_D_INO_IN_DIRENT\n+endif\n ifdef NO_STRCASESTR\n \tCOMPAT_CFLAGS += -DNO_STRCASESTR\n \tCOMPAT_OBJS += compat/strcasestr.o\ndiff --git a/fsck-objects.c b/fsck-objects.c\nindex 90e638e..9950be2 100644\n--- a/fsck-objects.c\n+++ b/fsck-objects.c\n@@ -20,6 +20,13 @@ static int check_strict = 0;\n static int keep_cache_objects = 0; \n static unsigned char head_sha1[20];\n \n+#if NO_D_INO_IN_DIRENT\n+#define SORT_DIRENT 0\n+#define DIRENT_SORT_HINT(de) 0\n+#else\n+#define SORT_DIRENT 1\n+#define DIRENT_SORT_HINT(de) ((de)->d_ino)\n+#endif\n \n static void objreport(struct object *obj, const char *severity,\n                       const char *err, va_list params)\n@@ -307,7 +314,9 @@ static void fsck_sha1_list(void)\n {\n \tint i, nr = sha1_list.nr;\n \n-\tqsort(sha1_list.entry, nr, sizeof(struct sha1_entry *), ino_compare);\n+\tif (SORT_DIRENT)\n+\t\tqsort(sha1_list.entry, nr,\n+\t\t      sizeof(struct sha1_entry *), ino_compare);\n \tfor (i = 0; i < nr; i++) {\n \t\tstruct sha1_entry *entry = sha1_list.entry[i];\n \t\tunsigned char *sha1 = entry->sha1;\n@@ -361,7 +370,7 @@ static int fsck_dir(int i, char *path)\n \t\t\tmemcpy(name+2, de->d_name, len+1);\n \t\t\tif (get_sha1_hex(name, sha1) < 0)\n \t\t\t\tbreak;\n-\t\t\tadd_sha1_list(sha1, de->d_ino);\n+\t\t\tadd_sha1_list(sha1, DIRENT_SORT_HINT(de));\n \t\t\tcontinue;\n \t\t}\n \t\tfprintf(stderr, \"bad sha1 file: %s/%s\\n\", path, de->d_name);\n-- \n1.1.3-gacdd\n"},{"id":"14935","messageId":"7voe277lbe.fsf@assigned-by-dhcp.cox.net","threadId":"3094","inReplyTo":"81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com","subject":"[PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-20T01:13:57Z","receivedAt":"2006-01-20T01:13:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The recent Cygwin defines DT_UNKNOWN although it does not have d_type\nin struct dirent.  Give an option to tell us not to use d_type on such\nplatforms.  Hopefully this problem will be transient.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n * By sending this out, I am not claiming this is better than\n   your version or anything like that.  This is just for\n   completeness and convenience, because my other two patches\n   touch overlapping areas in the same Makefile.  This patch\n   comes after the other two.\n\n Makefile |    7 +++++++\n cache.h  |    2 +-\n 2 files changed, 8 insertions(+), 1 deletions(-)\n\n80a4322a9bfbf0389ba8cb50f674682349f40a3a\ndiff --git a/Makefile b/Makefile\nindex 31898f7..84f5d24 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -21,6 +21,9 @@ all:\n #\n # Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.\n #\n+# Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks\n+# d_type in struct dirent (latest Cygwin -- will be fixed soonish).\n+#\n # Define NO_STRCASESTR if you don't have strcasestr.\n #\n # Define NO_SETENV if you don't have setenv in the C library.\n@@ -233,6 +236,7 @@ ifeq ($(uname_S),SunOS)\n \tALL_CFLAGS += -D__EXTENSIONS__\n endif\n ifeq ($(uname_O),Cygwin)\n+\tNO_D_TYPE_IN_DIRENT = YesPlease\n \tNO_D_INO_IN_DIRENT = YesPlease\n \tNO_STRCASESTR = YesPlease\n \tNEEDS_LIBICONV = YesPlease\n@@ -335,6 +339,9 @@ ifdef NEEDS_NSL\n \tLIBS += -lnsl\n \tSIMPLE_LIB += -lnsl\n endif\n+ifdef NO_D_TYPE_IN_DIRENT\n+\tALL_CFLAGS += -DNO_D_TYPE_IN_DIRENT\n+endif\n ifdef NO_D_INO_IN_DIRENT\n \tALL_CFLAGS += -DNO_D_INO_IN_DIRENT\n endif\ndiff --git a/cache.h b/cache.h\nindex 29c9e81..3d79c55 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -10,7 +10,7 @@\n #define deflateBound(c,s)  ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)\n #endif\n \n-#ifdef DT_UNKNOWN\n+#if defined(DT_UNKNOWN) && !NO_D_TYPE_IN_DIRENT\n #define DTYPE(de)\t((de)->d_type)\n #else\n #define DT_UNKNOWN\t0\n-- \n1.1.3-gacdd\n"},{"id":"14938","messageId":"20060120033803.GF5090@trixie.casa.cgf.cx","threadId":"3094","inReplyTo":"7vu0bz7lbk.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fsck-objects: support platforms without d_ino in struct dirent.","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-20T03:38:03Z","receivedAt":"2006-01-20T03:38:03Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jan 19, 2006 at 05:13:51PM -0800, Junio C Hamano wrote:\n>The d_ino field is only used for performance reasons in\n>fsck-objects.  On a typical filesystem, i-number tends to have a\n>strong correlation with where the actual bits sit on the disk\n>platter, and we sort the entries to allow us scan things that\n>ought to be close together together.\n>\n>If the platform lacks support for it, it is not a big deal.\n>Just do not use d_ino for sorting, and scan them unsorted.\n\nAh, interesting.  I don't know if the file id objects would have\nthat sort of correlation on NT but obviously the file hashes don't.\n\ncgf\n"},{"id":"14945","messageId":"81b0412b0601200523t14e3220fr9365c9e02a981abc@mail.gmail.com","threadId":"3094","inReplyTo":"7vzmlr7lc3.fsf@assigned-by-dhcp.cox.net","subject":"Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-20T13:23:14Z","receivedAt":"2006-01-20T13:23:14Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/20/06, Junio C Hamano <junkio@cox.net> wrote:\n> Just removing \"-Dsockaddr_storage=sockaddr_in\" from ALL_CFLAGS\n> seems to solve the problem for new Cygwin.\n>\n> I doubt that -Dsockaddr_storage=sockaddr_in should be tied to\n> NO_IPV6.  Maybe a better approach would be something like the\n> attached patch.\n>\n> Although /usr/include/cygwin/in.h seems to have struct sockaddr_in6,\n> getaddrinfo() and friends still do not seem to be there, so\n> NO_IPV6 still remains in effect on Cygwin.\n>\n> Comments?\n\nIt compiles, I don't think I can try the daemon though...\n"},{"id":"14950","messageId":"81b0412b0601200701n76f1d912y4671c6800735cd0d@mail.gmail.com","threadId":"3094","inReplyTo":"7voe277lbe.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-20T15:01:46Z","receivedAt":"2006-01-20T15:01:46Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/20/06, Junio C Hamano <junkio@cox.net> wrote:\n> The recent Cygwin defines DT_UNKNOWN although it does not have d_type\n> in struct dirent.  Give an option to tell us not to use d_type on such\n> platforms.  Hopefully this problem will be transient.\n\nYou still have to #undef all the DT_ macros if you have a somewhat old Cygwin\n(before Christopher removed the macros).\n"},{"id":"14962","messageId":"7vzmlqaf5o.fsf@assigned-by-dhcp.cox.net","threadId":"3094","inReplyTo":"81b0412b0601200701n76f1d912y4671c6800735cd0d@mail.gmail.com","subject":"Re: [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-20T19:10:59Z","receivedAt":"2006-01-20T19:10:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> writes:\n\n> On 1/20/06, Junio C Hamano <junkio@cox.net> wrote:\n>> The recent Cygwin defines DT_UNKNOWN although it does not have d_type\n>> in struct dirent.  Give an option to tell us not to use d_type on such\n>> platforms.  Hopefully this problem will be transient.\n>\n> You still have to #undef all the DT_ macros if you have a somewhat old Cygwin\n> (before Christopher removed the macros).\n> -\n\nAh, you mean something like this?\n\n-- >8 --\ndiff --git a/cache.h b/cache.h\nindex 8339931..6f13434 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -13,6 +13,10 @@\n #if defined(DT_UNKNOWN) && !NO_D_TYPE_IN_DIRENT\n #define DTYPE(de)\t((de)->d_type)\n #else\n+#undef DT_UNKNOWN\n+#undef DT_DIR\n+#undef DT_REG\n+#undef DT_LNK\n #define DT_UNKNOWN\t0\n #define DT_DIR\t\t1\n #define DT_REG\t\t2\n"},{"id":"14964","messageId":"20060120215314.GA4203@steel.home","threadId":"3094","inReplyTo":"7vzmlqaf5o.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-20T21:53:14Z","receivedAt":"2006-01-20T21:53:14Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Fri, Jan 20, 2006 20:10:59 +0100:\n> >> The recent Cygwin defines DT_UNKNOWN although it does not have d_type\n> >> in struct dirent.  Give an option to tell us not to use d_type on such\n> >> platforms.  Hopefully this problem will be transient.\n> >\n> > You still have to #undef all the DT_ macros if you have a somewhat\n> > old Cygwin (before Christopher removed the macros).\n> \n> Ah, you mean something like this?\n> \n> +#undef DT_UNKNOWN\n> +#undef DT_DIR\n> +#undef DT_REG\n> +#undef DT_LNK\n\nyes, of course\n"},{"id":"14973","messageId":"7vpsmmt32x.fsf@assigned-by-dhcp.cox.net","threadId":"3094","inReplyTo":"20060120215314.GA4203@steel.home","subject":"Re: [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-21T08:09:10Z","receivedAt":"2006-01-21T08:09:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> writes:\n\n>> +#undef DT_UNKNOWN\n>> +#undef DT_DIR\n>> +#undef DT_REG\n>> +#undef DT_LNK\n>\n> yes, of course\n\nThat is technically correct but I suspect it would not matter in\npractice.  The only thing you are avoiding is four compiler\nwarnings when compiling for Cygwin of this week (I heard this is\nalready fixed in Cygwin CVS).  On older Cygwin you simply would\nnot use NO_D_TYPE_IN_DIRENT, since d_type worked before.  No?\n"},{"id":"15069","messageId":"81b0412b0601230507n34311c14l5f1c14528f90ec14@mail.gmail.com","threadId":"3094","inReplyTo":"7vpsmmt32x.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-23T13:07:18Z","receivedAt":"2006-01-23T13:07:18Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/21/06, Junio C Hamano <junkio@cox.net> wrote:\n> Alex Riesen <raa.lkml@gmail.com> writes:\n>\n> >> +#undef DT_UNKNOWN\n> >> +#undef DT_DIR\n> >> +#undef DT_REG\n> >> +#undef DT_LNK\n> >\n> > yes, of course\n>\n> That is technically correct but I suspect it would not matter in\n> practice.  The only thing you are avoiding is four compiler\n> warnings when compiling for Cygwin of this week (I heard this is\n> already fixed in Cygwin CVS).  On older Cygwin you simply would\n> not use NO_D_TYPE_IN_DIRENT, since d_type worked before.  No?\n\nYes :)\n"}]}