{"thread":{"id":"6039","subject":"Re: [BUG] daemon.c blows up on OSX","startedAt":"2006-12-20T20:48:41Z","lastAt":"2007-01-03T15:25:38Z","messageCount":48,"participants":["Junio C Hamano","Terje Sten Bjerkseth","Randal L. Schwartz","Stefan Pfetzing","Johannes Schindelin","Marco Roeland","Shawn Pearce","Rocco Rutte","Andreas Ericsson","Linus Torvalds","Nicolas Pitre"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298580","messageId":"7vmz5ib8eu.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":null,"subject":"What's in git.git (stable), and Announcing GIT 1.4.4.3","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-20T20:48:41Z","receivedAt":"2006-12-20T20:48:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The latest maintenance release GIT 1.4.4.3 is available at the\nusual places:\n\n http://www.kernel.org/pub/software/scm/git/\n\n git-1.4.4.3.tar.{gz,bz2}\t\t\t(tarball)\n git-htmldocs-1.4.4.3.tar.{gz,bz2}\t\t(preformatted docs)\n git-manpages-1.4.4.3.tar.{gz,bz2}\t\t(preformatted docs)\n RPMS/$arch/git-*-1.4.4.3-1.$arch.rpm\t(RPM)\n\nThis release contains merge-recursive corner case fix; it also\nfixes git-cvsserver (when used with newer Perl) and Mac OS build\n(when you use config.mak), among other things.\n\nTo let people who only follow the 'maint' releases know what's\nhappening in the larger picture...\n\nWe have just started talking about the next feature release\nv1.5.0 on the 'master' branch side. If we are lucky we could do\na -rc1 around Christmas, emperor's birthday in Japan, or perhaps\nemperor's birthday in the Penguin land, but in any case the real\nrelease is not expected to happen by mid January.\n\nThe new release will have many end-user level changes since the\nlast feature release v1.4.4, both at the UI level and at the\ndocumentation level, based on previous discussions on the list.\n\nIt is strongly encouraged and very much appreciated to review\nand to fill gaps you would find in today's 'master' and what's\ncooking in 'next', if you were involved in the discussions\nand/or if you are interested in the theme of v1.5.0: \"usability\nand teachability\".\n\nThanks.\n\n-jc.\n\n----------------------------------------------------------------\n* The 'maint' branch is at v1.4.4.3 and has these fixes since\n v1.4.4.2:\n\n Alex Riesen (1):\n Clarify fetch error for missing objects.\n\n Brian Gernhardt (1):\n Move Fink and Ports check to after config file\n\n Chris Wright (1):\n no need to install manpages as executable\n\n Eric Wong (2):\n git-svn: exit with status 1 for test failures\n git-svn: correctly display fatal() error messages\n\n Jim Meyering (1):\n Don't use memcpy when source and dest. buffers may overlap\n\n Junio C Hamano (1):\n GIT 1.4.4.3\n\n Martin Langhoff (1):\n cvsserver: Avoid miscounting bytes in Perl v5.8.x\n\n Shawn Pearce (2):\n Make sure the empty tree exists when needed in merge-recursive.\n Bypass expensive content comparsion during rename detection.\n\n* The 'master' branch has these since the last announcement.\n They are NOT in 1.4.4.3.\n\n Aneesh Kumar K.V (1):\n Add config example with respect to branch\n\n Brian Gernhardt (2):\n Add documentation for show-branch --topics\n Remove COLLISION_CHECK from Makefile since it's not used.\n\n Eric Wong (1):\n git-cvsserver: fix breakage when calling git merge-file\n\n Jeff King (1):\n vim syntax: follow recent changes to commit template\n\n Junio C Hamano (8):\n parse-remote::expand_refs_wildcard()\n show-ref: fix --exclude-existing\n racy-git: documentation updates.\n rerere: fix breakage of resolving.\n fix populate-filespec\n config_rename_section: fix FILE* leak\n simplify inclusion of system header files.\n GIT 1.4.4.3\n\n Nicolas Pitre (4):\n make patch_delta() error cases a bit more verbose\n make git a bit less cryptic on fetch errors\n index-pack usage of mmap() is unacceptably slower on many OSes\n other than Linux\n clarify some error messages wrt unknown object types\n\n Robert Fitzsimons (1):\n gitweb: Show '...' links in \"summary\" view only if there are more items\n\n"},{"id":"294068","messageId":"86vek6z0k2.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"7vmz5ib8eu.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable), and Announcing GIT 1.4.4.3","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-20T22:04:29Z","receivedAt":"2006-12-20T22:04:29Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> * The 'master' branch has these since the last announcement.\nJunio> They are NOT in 1.4.4.3.\n\nJunio> index-pack usage of mmap() is unacceptably slower on many OSes\nJunio> other than Linux\n\nIs this really in master? I'm still seeing one-hour times on\nmy Mac, using 8336afa563fbeff35e531396273065161181f04c.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\n"},{"id":"295294","messageId":"Pine.LNX.4.64.0612201412250.3576@woody.osdl.org","threadId":"6039","inReplyTo":"86vek6z0k2.fsf@blue.stonehenge.com","subject":"Re: What's in git.git (stable), and Announcing GIT 1.4.4.3","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-20T22:14:38Z","receivedAt":"2006-12-20T22:14:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Dec 2006, Randal L. Schwartz wrote:\n> \n> Is this really in master? I'm still seeing one-hour times on\n> my Mac, using 8336afa563fbeff35e531396273065161181f04c.\n\nMaster right now is at 54851157ac.\n\nBut I use the master site of kernel.org, and the public site mirrors \nprobably haven't mirrored out yet.\n\nSometimes it can be worth it trying \"git2.kernel.org\" rather than \n\"git.kernel.org\", because the way the DNS round-robin works (badly), git1 \nseems to get a lot more load than git2, so sometimes git2 gets updated \nbefore git1 does.\n\n"},{"id":"294315","messageId":"7vvek66wlv.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"86vek6z0k2.fsf@blue.stonehenge.com","subject":"Re: What's in git.git (stable), and Announcing GIT 1.4.4.3","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-20T22:17:16Z","receivedAt":"2006-12-20T22:17:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> Is this really in master? I'm still seeing one-hour times on\n> my Mac, using 8336afa563fbeff35e531396273065161181f04c.\n\nI think you are behind rsync mirroring lag.\n\nLook for X-master-at: header in my message to see if you have\nthat commit, please.\n\n"},{"id":"297523","messageId":"Pine.LNX.4.64.0612201716270.18171@xanadu.home","threadId":"6039","inReplyTo":"86vek6z0k2.fsf@blue.stonehenge.com","subject":"Re: What's in git.git (stable), and Announcing GIT 1.4.4.3","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-20T22:19:46Z","receivedAt":"2006-12-20T22:19:46Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 20 Dec 2006, Randal L. Schwartz wrote:\n\n> >>>>> \"Junio\" == Junio C Hamano writes:\n> \n> Junio> * The 'master' branch has these since the last announcement.\n> Junio> They are NOT in 1.4.4.3.\n> \n> Junio> index-pack usage of mmap() is unacceptably slower on many OSes\n> Junio> other than Linux\n> \n> Is this really in master? I'm still seeing one-hour times on\n> my Mac, using 8336afa563fbeff35e531396273065161181f04c.\n\nIt is in current master, but not in 8336afa563fbeff35e5313...\n\nTo be sure you have it just open index-pack.c and make sure \"mmap\" is \nnot found there anymore.\n\n\n"},{"id":"294316","messageId":"86irg6yzt1.fsf_-_@blue.stonehenge.com","threadId":"6039","inReplyTo":"Pine.LNX.4.64.0612201412250.3576@woody.osdl.org","subject":"[BUG] daemon.c blows up on OSX (was Re: What's in git.git (stable), and Announcing GIT 1.4.4.3)","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-20T22:20:42Z","receivedAt":"2006-12-20T22:20:42Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\n>> Is this really in master? I'm still seeing one-hour times on\n>> my Mac, using 8336afa563fbeff35e531396273065161181f04c.\n\nLinus> Master right now is at 54851157ac.\n\nYeah, 54 objects just pulled down. Here we go. Time for a test...\n\nNope... can't compile:\n\n gcc -o daemon.o -c -g -O2 -Wall -I/sw/include -I/opt/local/include -DSHA1_HEADER='' -DNO_STRLCPY daemon.c\n daemon.c: In function 'parse_extra_args':\n daemon.c:414: warning: implicit declaration of function 'strncasecmp'\n daemon.c: In function 'socksetup':\n daemon.c:766: error: 'NI_MAXSERV' undeclared (first use in this function)\n daemon.c:766: error: (Each undeclared identifier is reported only once\n daemon.c:766: error: for each function it appears in.)\n daemon.c:766: warning: unused variable 'pbuf'\n daemon.c: In function 'serve':\n daemon.c:970: warning: implicit declaration of function 'initgroups'\n make: *** [daemon.o] Error 1\n\nThis smells like we've seen this before. Regression introduced with\nsome of the cleanup?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\n"},{"id":"297234","messageId":"7vr6uu6w8e.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"86irg6yzt1.fsf_-_@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-20T22:25:21Z","receivedAt":"2006-12-20T22:25:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> Nope... can't compile:\n> ...\n> daemon.c:970: warning: implicit declaration of function 'initgroups'\n> make: *** [daemon.o] Error 1\n>\n> This smells like we've seen this before. Regression introduced with\n> some of the cleanup?\n\nMost likely. You were CC'ed on these messages:\n\n\t<7v7iwnnzed.fsf@assigned-by-dhcp.cox.net>\n\t<7vbqlye2zz.fsf@assigned-by-dhcp.cox.net>\n\n"},{"id":"294756","messageId":"86ejquyz4v.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"7vr6uu6w8e.fsf@assigned-by-dhcp.cox.net","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-20T22:35:12Z","receivedAt":"2006-12-20T22:35:12Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> merlyn@stonehenge.com (Randal L. Schwartz) writes:\n>> Nope... can't compile:\n>> ...\n>> daemon.c:970: warning: implicit declaration of function 'initgroups'\n>> make: *** [daemon.o] Error 1\n>> \n>> This smells like we've seen this before. Regression introduced with\n>> some of the cleanup?\n\nJunio> Most likely. You were CC'ed on these messages:\n\nJunio> \t<7v7iwnnzed.fsf@assigned-by-dhcp.cox.net>\nJunio> \t<7vbqlye2zz.fsf@assigned-by-dhcp.cox.net>\n\nI see in 979e32fa1483a32faa4ec331e29b357e5eb5ef25 that I had to change\nsome things for OpenBSD... I bet those are generic BSD things.\n\nLemme see if it breaks on OpenBSD as well.\n\nOddly enough - it didn't. :)\n\nrunning \"git version 1.4.4.3.g5485\" on my openbsd box, but I can't get\nthere on my OSX box.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\n"},{"id":"297985","messageId":"7vhcvq6vcx.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"86ejquyz4v.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-20T22:44:14Z","receivedAt":"2006-12-20T22:44:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> Lemme see if it breaks on OpenBSD as well.\n>\n> Oddly enough - it didn't. :)\n\nOf course it didn't. I was a bit more careful than usual with\nthis and fired up an OpenBSD bochs on my wife's machine to test\nit before pushing out.\n\n> running \"git version 1.4.4.3.g5485\" on my openbsd box, but I can't get\n> there on my OSX box.\n\nSorry, I cannot be of immediate help -- I do not have one.\n\n"},{"id":"296433","messageId":"86ac1iyyla.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"86ejquyz4v.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-20T22:46:57Z","receivedAt":"2006-12-20T22:46:57Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Randal\" == Randal L Schwartz writes:\n\nRandal> running \"git version 1.4.4.3.g5485\" on my openbsd box, but I can't get\nRandal> there on my OSX box.\n\nAccording to my headers, \"strncasecmp\" is defined in ,\n\"NI_MAXSERV\" is defined in , and \"initgrps\" is defined\nin \"unistd.h\". So this patch works (just verified on OSX), but I\ndon't know what damage it does elsehwere:\n\ndiff --git a/daemon.c b/daemon.c\nindex b129b83..5ce73ed 100644\n--- a/daemon.c\n+++ b/daemon.c\n@@ -1,3 +1,7 @@\n+#include \n+#include \n+#include \n+\n #include \"cache.h\"\n #include \"pkt-line.h\"\n #include \"exec_cmd.h\"\n\nHowever, now imap-send.o blows up:\n\nimap-send.c: In function 'imap_open_store':\nimap-send.c:908: error: 'AF_LOCAL' undeclared (first use in this function)\nimap-send.c:908: error: (Each undeclared identifier is reported only once\nimap-send.c:908: error: for each function it appears in.)\nimap-send.c:990: warning: implicit declaration of function 'getpass'\nimap-send.c:990: warning: assignment makes pointer from integer without a cast\nmake: *** [imap-send.o] Error 1\n\nand finding \"getpass\" wants me to add \"unistd.h\" there too.\n\nHmm. Let's see if I can use git-format-patch as Linus intended.\n\n\n\nFrom 1549561dc68a1ea71f137c40109c90d33c0f9887 Mon Sep 17 00:00:00 2001\nFrom: Randal L. Schwartz \nDate: Wed, 20 Dec 2006 14:45:49 -0800\nSubject: [PATCH] patch for osx\n\n---\n daemon.c | 4 ++++\n imap-send.c | 2 ++\n 2 files changed, 6 insertions(+), 0 deletions(-)\n\ndiff --git a/daemon.c b/daemon.c\nindex b129b83..5ce73ed 100644\n--- a/daemon.c\n+++ b/daemon.c\n@@ -1,3 +1,7 @@\n+#include \n+#include \n+#include \n+\n #include \"cache.h\"\n #include \"pkt-line.h\"\n #include \"exec_cmd.h\"\ndiff --git a/imap-send.c b/imap-send.c\nindex 894cbbd..afd7447 100644\n--- a/imap-send.c\n+++ b/imap-send.c\n@@ -22,6 +22,8 @@\n * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n */\n \n+#include \n+\n #include \"cache.h\"\n \n typedef struct store_conf {\n-- \n1.4.4.3.g5485-dirty\n\n\n\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"294361","messageId":"7v1wmu6ugr.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"86ac1iyyla.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-20T23:03:32Z","receivedAt":"2006-12-20T23:03:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Randal\" == Randal L Schwartz writes:\n>\n> Randal> running \"git version 1.4.4.3.g5485\" on my openbsd box, but I can't get\n> Randal> there on my OSX box.\n>\n> According to my headers, \"strncasecmp\" is defined in ,\n> \"NI_MAXSERV\" is defined in , and \"initgrps\" is defined\n> in \"unistd.h\". So this patch works (just verified on OSX), but I\n> don't know what damage it does elsehwere:\n>\n> diff --git a/daemon.c b/daemon.c\n> index b129b83..5ce73ed 100644\n> --- a/daemon.c\n> +++ b/daemon.c\n> @@ -1,3 +1,7 @@\n> +#include \n> +#include \n> +#include \n> +\n> #include \"cache.h\"\n\nThis unfortunately violates the \"all common system headers in\ngit-compat-util.h\" rule, which is needed to define _XOPEN_SOURCE\nand friends before including the system header files.\n\nAnd string.h, netdb.h and unistd.h are already included there,\nso there is something deeper going on on OSX.\n\nIs the declaration of strncasecmp in on OSX\nconditional to some macro (and the same question about other\nsymbols you did not get)? We need to find out what feature\nmacros are expected on that platform and define them as needed.\n\nFor example, on OpenBSD, does not expose u_int\nwithout __BSD_VISIBLE, and its header uses that\ntype. The source files (user programs, that's us) are expected\nto include sys/types.h before including netinet/tcp.h *AND*\nexpected to somehow cause __BSD_VISIBLE be defined before\nincluding sys/types.h. That's why we have _BSD_SOURCE in our\ngit-compat-util.h header file (_XOPEN_SOURCE and _GNU_SOURCE\nserve similar purposes for various other systems).\n"},{"id":"297269","messageId":"Pine.LNX.4.64.0612201502090.3576@woody.osdl.org","threadId":"6039","inReplyTo":"86ac1iyyla.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-20T23:07:54Z","receivedAt":"2006-12-20T23:07:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Dec 2006, Randal L. Schwartz wrote:\n> \n> According to my headers, \"strncasecmp\" is defined in ,\n> \"NI_MAXSERV\" is defined in , and \"initgrps\" is defined\n> in \"unistd.h\". So this patch works (just verified on OSX), but I\n> don't know what damage it does elsehwere:\n\nLook at \"cache.h\": the first thing it does is to include \n\"git-compat-util.h\". And THAT in turn does include ALL the headers you \nadded (string.h, netdb.h and unistd.h).\n\nSo it would appear that for OS X, the\n\n\t#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n\t#define _GNU_SOURCE\n\t#define _BSD_SOURCE\n\nsequence actually _disables_ those things.\n\nSome googling finds a python source diff:\n\n\t # On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE\n\t # disables platform specific features beyond repair.\n\t- Darwin/8.*)\n\t+ Darwin/8.*|Darwin/7.*)\n\t define_xopen_source=no\n\t ;;\n\n(and Ruby shows up as well in the google)\n\nCan you try to grovel around in the OS X headers, and see what the magic \nis to enable all the compatibility crud on OS X?\n\n"},{"id":"295214","messageId":"86wt4mximh.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"Pine.LNX.4.64.0612201502090.3576@woody.osdl.org","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-20T23:17:10Z","receivedAt":"2006-12-20T23:17:10Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\nLinus> \t#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\nLinus> \t#define _GNU_SOURCE\nLinus> \t#define _BSD_SOURCE\n\nWell, _GNU_SOURCE and _BSD_SOURCE only get defined, and only by some\noddballs that aren't relevant here.\n\nLinus> sequence actually _disables_ those things.\n\nLinus> Some googling finds a python source diff:\n\nLinus> \t # On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE\nLinus> \t # disables platform specific features beyond repair.\nLinus> \t- Darwin/8.*)\nLinus> \t+ Darwin/8.*|Darwin/7.*)\nLinus> \t define_xopen_source=no\nLinus> \t ;;\n\nLinus> (and Ruby shows up as well in the google)\n\nLinus> Can you try to grovel around in the OS X headers, and see what the magic \nLinus> is to enable all the compatibility crud on OS X?\n\n\nBut yes, _XOPEN_SOURCE_EXTENDED definitely does some damage to\ncurses.h. However, I don't see how that's relevant to strings.h\nor the others I need. There's no \"config\" for \"compatibility\".\nWelcome to Linux vs Unix. :)\n\nWhat I do know is (a) it worked before the header changes and (b)\nthe patch I just gave you works. If the patch doesn't break others,\ncan we just leave it in?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\n"},{"id":"296547","messageId":"86r6uuxi8o.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"7v1wmu6ugr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-20T23:25:27Z","receivedAt":"2006-12-20T23:25:27Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> This unfortunately violates the \"all common system headers in\nJunio> git-compat-util.h\" rule, which is needed to define _XOPEN_SOURCE\nJunio> and friends before including the system header files.\n\nJunio> And string.h, netdb.h and unistd.h are already included there,\nJunio> so there is something deeper going on on OSX.\n\nJunio> Is the declaration of strncasecmp in on OSX\nJunio> conditional to some macro (and the same question about other\nJunio> symbols you did not get)? We need to find out what feature\nJunio> macros are expected on that platform and define them as needed.\n\nIf one of those defines _POSIX_C_SOURCE (or _ANSI_SOURCE),\nthen does *not* define \"strncasecmp\", because it has those\nunder a comment of \"Nonstandard routines\".\n\nIs anything earlier defining one of these?\n\nAnd yes, netdb.h also has a lot of those depending on _POSIX_C_SOURCE,\nand so does unistd.h\n\nSo that's your culprit. You're defining _POSIX_C_SOURCE when you're\nnot really proper _POSIX_C compliant. Can you just remove that?\n\nAnd sys/cdefs.h for darwin has this:\n\n /* Deal with various X/Open Portability Guides and Single UNIX Spec. */\n #ifdef _XOPEN_SOURCE\n #if _XOPEN_SOURCE - 0L >= 600L\n #undef _POSIX_C_SOURCE\n #define _POSIX_C_SOURCE 200112L\n #elif _XOPEN_SOURCE - 0L >= 500L\n #undef _POSIX_C_SOURCE\n #define _POSIX_C_SOURCE 199506L\n #endif\n #endif\n\nSo that's likely how _POSIX_C_SOURCE is getting defined for the rest.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\n"},{"id":"294744","messageId":"7v64c65emt.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"86wt4mximh.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-20T23:30:50Z","receivedAt":"2006-12-20T23:30:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> But yes, _XOPEN_SOURCE_EXTENDED definitely does some damage to\n> curses.h. However, I don't see how that's relevant to strings.h\n> or the others I need. There's no \"config\" for \"compatibility\".\n> Welcome to Linux vs Unix. :)\n>\n> What I do know is (a) it worked before the header changes and (b)\n> the patch I just gave you works. If the patch doesn't break others,\n> can we just leave it in?\n\nThat would lead to maintenance nightmare in the longer term. We\ncannot do that unless we know more or less what is going on.\nIncluding only some system headers in a random order before\nfeature macros are defined, and doing so in only some source\nfiles randomly until it starts compiling, is not a solution\nmaintainable in the longer term.\n\nThe _EXTENDED stuff is minimally commented that AIX wants it;\notherwise we would have been tempted to say, \"remove it, if it\nbreaks OSX\" without thinking, and would have ended up breaking\nAIX.\n\nNo matter what we do, I would really want a clear description of\nin what way OSX headers are broken and what needs to be done to\navoid the breakage in git-compat-util.h where it sets up feature\nmacros and includes system headers.\n\n"},{"id":"29888","messageId":"86irg6xht8.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"86r6uuxi8o.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-20T23:34:43Z","receivedAt":"2006-12-20T23:34:43Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Randal\" == Randal L Schwartz writes:\n\nRandal> So that's likely how _POSIX_C_SOURCE is getting defined for the rest.\n\nUnfortunately, just deleting the two _XOPEN_SOURCE entries in\ngit-compat-util.h doesn't do it, even for OSX. So something more convoluted\nhere is going on.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"294065","messageId":"Pine.LNX.4.64.0612201524230.3576@woody.osdl.org","threadId":"6039","inReplyTo":"86wt4mximh.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-20T23:41:32Z","receivedAt":"2006-12-20T23:41:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 20 Dec 2006, Randal L. Schwartz wrote:\n> \n> What I do know is (a) it worked before the header changes and (b)\n> the patch I just gave you works. If the patch doesn't break others,\n> can we just leave it in?\n\nWell, at some point it probably _will_ break on other systems, exactly \nbecause other systems want to have the extended declarations.\n\nIt would be much better to have all the weird system dependencies solved \nin ONE place, rather than have each file (depending on just what they \nhappen to need) have their own hacks for each weird system header file \nsituation.\n\nSo it really would be a hell of a lot better to figure out _why_ strings.h \ndoesn't \"just work\" when _XOPEN_SOURCE_EXTENDED is set. Or if there are \nbetter alternatives that work on HP-UX.. \n\nDoes adding a\n\n\t#define _SVID_SOURCE 1\n\nhelp? Also, we should probably make the _GNU_SOURCE and _BSD_SOURCE \ndefines define to 1 (which is the way they'd be if we used -D_GNU_SOURCE \non the compiler command line)\n\nIOW, the appended ...\n\nThe really sad part is that this seems to be an OS X _bug_. \n\"strncasecmp()\" is part of the standard Open UNIX definitions, it's not \nsomething that should be shut off by _XOPEN_SOURCE, afaik.\n\nThere were apparently some OS X developers on the git list, mind \ncommenting on this?\n\n\t\tLinus\n\n---\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex bc296b3..1400905 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -13,8 +13,9 @@\n \n #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */\n #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n-#define _GNU_SOURCE\n-#define _BSD_SOURCE\n+#define _GNU_SOURCE 1\n+#define _BSD_SOURCE 1\n+#define _SVID_SOURCE 1\n \n #include \n"},{"id":"29889","messageId":"86ejquxgpd.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"Pine.LNX.4.64.0612201412250.3576@woody.osdl.org","subject":"Re: What's in git.git (stable), and Announcing GIT 1.4.4.3","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-20T23:58:38Z","receivedAt":"2006-12-20T23:58:38Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\nLinus> Master right now is at 54851157ac.\n\nOn a more positive note, with my local (unacceptable) changes to muck with\nheaders, the 54 release does in fact make git-index-pack take\nunder a minute for 313037 objects on OSX. Yeay!\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"297343","messageId":"caf068570612201636g75180138r223aef7c42f69a50@mail.gmail.com","threadId":"6039","inReplyTo":"Pine.LNX.4.64.0612201524230.3576@woody.osdl.org","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Terje Sten Bjerkseth","fromEmail":"terje@bjerkseth.org","sentAt":"2006-12-21T00:36:44Z","receivedAt":"2006-12-21T00:36:44Z","isPatch":false,"sender":{"key":"terje@bjerkseth.org","avatar":null},"body":"On 12/21/06, Linus Torvalds wrote:\n> So it really would be a hell of a lot better to figure out _why_ strings.h\n> doesn't \"just work\" when _XOPEN_SOURCE_EXTENDED is set. Or if there are\n> better alternatives that work on HP-UX..\n>\n> Does adding a\n>\n> #define _SVID_SOURCE 1\n>\n> help? Also, we should probably make the _GNU_SOURCE and _BSD_SOURCE\n> defines define to 1 (which is the way they'd be if we used -D_GNU_SOURCE\n> on the compiler command line)\n>\n> IOW, the appended ...\n\nFor Mac OS X 10.4, _XOPEN_SOURCE seems to define _POSIX_C_SOURCE which\ncauses the NI_MAXSERV problem in netdb.h. The appended seems to make\nit work.\n\n--\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex bc296b3..41fa7f6 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -11,8 +11,10 @@\n\n #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n\n+#ifndef __APPLE_CC__\n #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD\nneeds 600 for S_ISLNK() */\n #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n+#endif\n #define _GNU_SOURCE\n"},{"id":"298098","messageId":"7vtzzq3wo6.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"caf068570612201636g75180138r223aef7c42f69a50@mail.gmail.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-21T00:44:09Z","receivedAt":"2006-12-21T00:44:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Terje Sten Bjerkseth\" writes:\n\n> On 12/21/06, Linus Torvalds wrote:\n>> So it really would be a hell of a lot better to figure out _why_ strings.h\n>> doesn't \"just work\" when _XOPEN_SOURCE_EXTENDED is set. Or if there are\n>> better alternatives that work on HP-UX..\n>>\n>> Does adding a\n>>\n>> #define _SVID_SOURCE 1\n>>\n>> help? Also, we should probably make the _GNU_SOURCE and _BSD_SOURCE\n>> defines define to 1 (which is the way they'd be if we used -D_GNU_SOURCE\n>> on the compiler command line)\n>>\n>> IOW, the appended ...\n>\n> For Mac OS X 10.4, _XOPEN_SOURCE seems to define _POSIX_C_SOURCE which\n> causes the NI_MAXSERV problem in netdb.h. The appended seems to make\n> it work.\n>\n> --\n> diff --git a/git-compat-util.h b/git-compat-util.h\n> index bc296b3..41fa7f6 100644\n> --- a/git-compat-util.h\n> +++ b/git-compat-util.h\n> @@ -11,8 +11,10 @@\n>\n> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n>\n> +#ifndef __APPLE_CC__\n> #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD\n> needs 600 for S_ISLNK() */\n> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n> +#endif\n> #define _GNU_SOURCE\n> #define _BSD_SOURCE\n\nThanks. While this is in a better direction than randomly\nincluding the headers in the source, it is still sad.\n\nDoes everybody use Apple CC on OSX? Is the symbol defined even\nwith GCC? Or Gcc fixes headers well enough and makes this a\nnon-issue?\n"},{"id":"296219","messageId":"Pine.LNX.4.64.0612201643520.3576@woody.osdl.org","threadId":"6039","inReplyTo":"caf068570612201636g75180138r223aef7c42f69a50@mail.gmail.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-21T00:44:35Z","receivedAt":"2006-12-21T00:44:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 21 Dec 2006, Terje Sten Bjerkseth wrote:\n> \n> For Mac OS X 10.4, _XOPEN_SOURCE seems to define _POSIX_C_SOURCE which\n> causes the NI_MAXSERV problem in netdb.h. The appended seems to make\n> it work.\n\nOk, that's probably the best we can do. Along with perhaps cursing at \napple a bit.\n\nYour patch is whitespace-damaged, btw.\n\n"},{"id":"295818","messageId":"caf068570612201654s3949202cl55bd21307ca59453@mail.gmail.com","threadId":"6039","inReplyTo":"7vtzzq3wo6.fsf@assigned-by-dhcp.cox.net","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Terje Sten Bjerkseth","fromEmail":"terje@bjerkseth.org","sentAt":"2006-12-21T00:54:06Z","receivedAt":"2006-12-21T00:54:06Z","isPatch":false,"sender":{"key":"terje@bjerkseth.org","avatar":null},"body":"On 12/21/06, Junio C Hamano wrote:\n> Thanks. While this is in a better direction than randomly\n> including the headers in the source, it is still sad.\n>\n> Does everybody use Apple CC on OSX? Is the symbol defined even\n> with GCC? Or Gcc fixes headers well enough and makes this a\n> non-issue?\n\nI'm not sure about everybody, but at least the Apple CC *is* GCC:\n\n~/src/git terjesb$ cc --version\ni686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)\nCopyright (C) 2005 Free Software Foundation, Inc.\n\nso this is probably a non-issue for default setups. (Sorry about the\n"},{"id":"297273","messageId":"7vodpy3vxi.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"caf068570612201654s3949202cl55bd21307ca59453@mail.gmail.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-21T01:00:09Z","receivedAt":"2006-12-21T01:00:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Terje Sten Bjerkseth\" writes:\n\n> On 12/21/06, Junio C Hamano wrote:\n>> Thanks. While this is in a better direction than randomly\n>> including the headers in the source, it is still sad.\n>>\n>> Does everybody use Apple CC on OSX? Is the symbol defined even\n>> with GCC? Or Gcc fixes headers well enough and makes this a\n>> non-issue?\n>\n> I'm not sure about everybody, but at least the Apple CC *is* GCC:\n\nThanks for clarifying this; will apply.\n"},{"id":"296755","messageId":"86ac1ixdic.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"Pine.LNX.4.64.0612201643520.3576@woody.osdl.org","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-21T01:07:39Z","receivedAt":"2006-12-21T01:07:39Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\nLinus> Your patch is whitespace-damaged, btw.\n\nThe version as an attachment shouldn't have been.\n\nThe cut-n-paste might have been.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\n"},{"id":"293813","messageId":"8664c6xdgi.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"caf068570612201636g75180138r223aef7c42f69a50@mail.gmail.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-21T01:08:45Z","receivedAt":"2006-12-21T01:08:45Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Terje\" == Terje Sten Bjerkseth writes:\n\n\nTerje> +#ifndef __APPLE_CC__\nTerje> #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD\nTerje> needs 600 for S_ISLNK() */\nTerje> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\nTerje> +#endif\nTerje> #define _GNU_SOURCE\nTerje> #define _BSD_SOURCE\nTerje> -\n\nI tried the moral equivalent of that, and it failed to compile many\nother things then. So that's not it.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\n"},{"id":"296978","messageId":"7vk60m3vby.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"86ac1ixdic.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-21T01:13:05Z","receivedAt":"2006-12-21T01:13:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Linus\" == Linus Torvalds writes:\n>\n> Linus> Your patch is whitespace-damaged, btw.\n>\n> The version as an attachment shouldn't have been.\n>\n> The cut-n-paste might have been.\n\nWhile I do not have a clue on what point you are trying to make,\nI have a more important question for you.\n\nDoes Terje's patch fix it for you?\n\n\n"},{"id":"296077","messageId":"86vek6vyc7.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"7vodpy3vxi.fsf@assigned-by-dhcp.cox.net","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-21T01:20:40Z","receivedAt":"2006-12-21T01:20:40Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> \"Terje Sten Bjerkseth\" writes:\n>> On 12/21/06, Junio C Hamano wrote:\n>>> Thanks. While this is in a better direction than randomly\n>>> including the headers in the source, it is still sad.\n>>> \n>>> Does everybody use Apple CC on OSX? Is the symbol defined even\n>>> with GCC? Or Gcc fixes headers well enough and makes this a\n>>> non-issue?\n>> \n>> I'm not sure about everybody, but at least the Apple CC *is* GCC:\n\nJunio> Thanks for clarifying this; will apply.\n\nBut don't because it doesn't help. :(\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\n"},{"id":"29883","messageId":"7vd56e3ukv.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"86vek6vyc7.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-21T01:29:20Z","receivedAt":"2006-12-21T01:29:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>> I'm not sure about everybody, but at least the Apple CC *is* GCC:\n>\n> Junio> Thanks for clarifying this; will apply.\n>\n> But don't because it doesn't help. :(\n\nWon't; thanks for catching me soon enough.\n"},{"id":"29884","messageId":"caf068570612201735o776e01a8he2e9ab90fc2ee4f@mail.gmail.com","threadId":"6039","inReplyTo":"86vek6vyc7.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Terje Sten Bjerkseth","fromEmail":"terje@bjerkseth.org","sentAt":"2006-12-21T01:35:08Z","receivedAt":"2006-12-21T01:35:08Z","isPatch":false,"sender":{"key":"terje@bjerkseth.org","avatar":null},"body":"On 20 Dec 2006 17:20:40 -0800, Randal L. Schwartz wrote:\n> >>>>> \"Junio\" == Junio C Hamano writes:\n> Junio> Thanks for clarifying this; will apply.\n>\n> But don't because it doesn't help. :(\n\nIt definitely works here with it. This is on Mac OS X 10.4.8 (Intel)\nwith default GCC 4.0.1 from Developer Tools.\n\nWhich version are you using? Does it work if you change from testing\n__APPLE_CC__ to just __APPLE__? That also works here, and is probably\nbetter anyway. (Perhaps you are using an earlier version and the\nformer define was introduced with gcc 4.0 to separate gcc compiler\nversions.)\n"},{"id":"29885","messageId":"86psaevxo3.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"24BF45E9-DD98-4609-9D65-B01EAA30CCA8@silverinsanity.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-21T01:35:08Z","receivedAt":"2006-12-21T01:35:08Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Brian\" == Brian Gernhardt writes:\n\nBrian> On Dec 20, 2006, at 8:08 PM, Randal L. Schwartz wrote:\n\n>>>>>>> \"Terje\" == Terje Sten Bjerkseth writes:\n>> \n>> \nTerje> +#ifndef __APPLE_CC__\nTerje> #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD\nTerje> needs 600 for S_ISLNK() */\nTerje> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\nTerje> +#endif\nTerje> #define _GNU_SOURCE\nTerje> #define _BSD_SOURCE\nTerje> -\n>> \n>> I tried the moral equivalent of that, and it failed to compile many\n>> other things then. So that's not it.\n\nBrian> Well, it seems to work for me as is (although I applied it manually instead\nBrian> of dealing with copy/paste with a patch).\n\nI did it with #if 0 / #end instead of the __APPLE_CC__ symbol.\nBut, weirdly, now that I used the symbol, I get a good compile.\n\nDoes #if 0 not work? :)\n\nSorry for being objectionable earlier then. I've attached the precise\npatch I used and works and verified.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n\n\n>From 9e3f88df3f6b17804f53fb497202f0879ea5e5f3 Mon Sep 17 00:00:00 2001\nFrom: Randal L. Schwartz \nDate: Wed, 20 Dec 2006 17:32:21 -0800\nSubject: [PATCH] patch-from-email\n\n---\n git-compat-util.h | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex bc296b3..41fa7f6 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -11,8 +11,10 @@\n \n #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n \n+#ifndef __APPLE_CC__\n #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */\n #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n+#endif\n #define _GNU_SOURCE\n #define _BSD_SOURCE\n \n-- \n1.4.4.3.g9e3f8\n\n"},{"id":"29886","messageId":"7v64c63tol.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"86psaevxo3.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-21T01:48:42Z","receivedAt":"2006-12-21T01:48:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>> I tried the moral equivalent of that, and it failed to compile many\n>>> other things then. So that's not it.\n> ...\n> I did it with #if 0 / #end instead of the __APPLE_CC__ symbol.\n> But, weirdly, now that I used the symbol, I get a good compile.\n> ...\n> Sorry for being objectionable earlier then. I've attached the precise\n> patch I used and works and verified.\n\nJust to make sure... the attached looks exactly what Terje's\npatch would have been before the whitespace damage. Can I take\nthis as confirmation that the patch works for you and Terje?\n\nI wonder what the earlier failure you got from \"the moral\nequivalent\" was -- I hope it is not an indication that we have a\ndependency bug in our Makefile somewhere.\n\nThanks.\n\n> diff --git a/git-compat-util.h b/git-compat-util.h\n> index bc296b3..41fa7f6 100644\n> --- a/git-compat-util.h\n> +++ b/git-compat-util.h\n> @@ -11,8 +11,10 @@\n> \n> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n> \n> +#ifndef __APPLE_CC__\n> #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */\n> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n> +#endif\n> #define _GNU_SOURCE\n> #define _BSD_SOURCE\n> \n> -- \n> 1.4.4.3.g9e3f8\n"},{"id":"29887","messageId":"86hcvqvwyd.fsf@blue.stonehenge.com","threadId":"6039","inReplyTo":"7v64c63tol.fsf@assigned-by-dhcp.cox.net","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-12-21T01:50:34Z","receivedAt":"2006-12-21T01:50:34Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> Just to make sure... the attached looks exactly what Terje's\nJunio> patch would have been before the whitespace damage. Can I take\nJunio> this as confirmation that the patch works for you and Terje?\n\nThe patch I uploaded should be character-equivalent to Terje's.\nI don't know what \"whitespace damage\" you're referencing.\n\nJunio> I wonder what the earlier failure you got from \"the moral\nJunio> equivalent\" was -- I hope it is not an indication that we have a\nJunio> dependency bug in our Makefile somewhere.\n\nYeah, I'm not sure why\n\n#if 0\nthose two defines\n#end\n\ndoesn't do the same thing. Oh well, shrug.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"29890","messageId":"7vy7p22epw.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"86hcvqvwyd.fsf@blue.stonehenge.com","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-21T01:57:15Z","receivedAt":"2006-12-21T01:57:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> The patch I uploaded should be character-equivalent to Terje's.\n\nThanks.\n\n> I don't know what \"whitespace damage\" you're referencing.\n\nAha, it was undamaged but rendered as if it were, because it was\nof \"content-type: text/plain; format=flawed\".\n"},{"id":"29891","messageId":"f3d7535d0612201804r4b80545esd59b374ce8456457@mail.gmail.com","threadId":"6039","inReplyTo":"86irg6xht8.fsf@blue.stonehenge.com","subject":"Re: Re: [BUG] daemon.c blows up on OSX","fromName":"Stefan Pfetzing","fromEmail":"stefan.pfetzing@gmail.com","sentAt":"2006-12-21T02:04:11Z","receivedAt":"2006-12-21T02:04:11Z","isPatch":false,"sender":{"key":"stefan.pfetzing@gmail.com","avatar":null},"body":"Hi,\n\n20 Dec 2006 15:34:43 -0800, Randal L. Schwartz :\n>\n> Unfortunately, just deleting the two _XOPEN_SOURCE entries in\n> git-compat-util.h doesn't do it, even for OSX. So something more convoluted\n> here is going on.\n\nHm, very strange - for me the patch mentioned here works fine. (Mac OS\nX 10.4.8 on an Intel Mac)\n\nbye\n\ndreamind\n\n-- \n http://www.dreamind.de/\nOroborus and Debian GNU/Linux Developer.\n"},{"id":"29912","messageId":"Pine.LNX.4.63.0612210942580.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6039","inReplyTo":"7vvek66wlv.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable), and Announcing GIT 1.4.4.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-21T08:43:13Z","receivedAt":"2006-12-21T08:43:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 20 Dec 2006, Junio C Hamano wrote:\n\n> Look for X-master-at: header in my message to see if you have that \n> commit, please.\n\nNice!\n\nCiao,\nDscho\n"},{"id":"29915","messageId":"7v3b79eima.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"Pine.LNX.4.63.0612210942580.19693@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git (stable), and Announcing GIT 1.4.4.3","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-21T08:52:13Z","receivedAt":"2006-12-21T08:52:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Wed, 20 Dec 2006, Junio C Hamano wrote:\n>\n>> Look for X-master-at: header in my message to see if you have that \n>> commit, please.\n>\n> Nice!\n\nSorry for not advertising. The header has been there for a long\ntime.\n"},{"id":"29930","messageId":"20061221103938.GA7055@fiberbit.xs4all.nl","threadId":"6039","inReplyTo":"caf068570612201735o776e01a8he2e9ab90fc2ee4f@mail.gmail.com","subject":"[PATCH] Do not define _XOPEN_SOURCE on MacOSX as it is too restricting there","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-12-21T10:39:38Z","receivedAt":"2006-12-21T10:39:38Z","isPatch":true,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"Defining _XOPEN_SOURCE on Darwin always leads to a restricted set of\navailable functions and symbols. This can not be cured by adding extra\ndefines in any way. So there really is only the choice between _not_\ndefining this symbol on Mac OS X or restricting our usage of functions\nand symbols to the POSIX sets that are in term implied by _XOPEN_SOURCE.\nThe first seems better.\n\nNote the last three lines from this following literal code snippet in\n/usr/include/sys/cdefs.h from the Apple Darwin sources:\n\n * By default newly complied code will actually get the same symbols\n * that the old code did. Defining any of _APPLE_C_SOURCE, _XOPEN_SOURCE,\n * or _POSIX_C_SOURCE will give you the new symbols. Defining _XOPEN_SOURCE\n * or _POSIX_C_SOURCE also restricts the avilable symbols to a subset of\n * Apple's APIs.\n\nWe want our symbols \"avilable\" so lets not use _XOPEN_SOURCE on Darwin!\n\nThe preferred way of checking specific Apple specific issues is by using\nthe __APPLE__ predefined macro.\n\nThe extra define _XOPEN_SOURCE_EXTENDED does only affect some headers\n(like the /usr/include/curses.h header) and can stay.\n\nPatch from Terje Sten Bjerkseth, only added a comment.\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex bc296b3..f056d20 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -11,7 +11,11 @@\n \n #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n \n+#if !defined __APPLE__\n #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */\n+#else\n+\t\t\t/* On Darwin defining _XOPEN_SOURCE always restricts available functions */\n+#endif\n #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n #define _GNU_SOURCE\n #define _BSD_SOURCE\n"},{"id":"29935","messageId":"20061221112835.GA7713@fiberbit.xs4all.nl","threadId":"6039","inReplyTo":"20061221103938.GA7055@fiberbit.xs4all.nl","subject":"[PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-12-21T11:28:35Z","receivedAt":"2006-12-21T11:28:35Z","isPatch":true,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"Defining _XOPEN_SOURCE on Darwin always leads to a restricted set of\navailable functions and symbols. This can not be cured by adding extra\ndefines in any way. So there really is only the choice between _not_\ndefining this symbol on Mac OS X or restricting our usage of functions\nand symbols to the POSIX sets that are in term implied by _XOPEN_SOURCE.\nThe first seems better.\n\nNote the last three lines from this following literal code snippet in\n/usr/include/sys/cdefs.h from the Apple Darwin sources:\n\n * By default newly complied code will actually get the same symbols\n * that the old code did. Defining any of _APPLE_C_SOURCE, _XOPEN_SOURCE,\n * or _POSIX_C_SOURCE will give you the new symbols. Defining _XOPEN_SOURCE\n * or _POSIX_C_SOURCE also restricts the avilable symbols to a subset of\n * Apple's APIs.\n\nWe want our symbols \"avilable\" so lets not use _XOPEN_SOURCE on Darwin!\n\nThe preferred way of checking specific Apple specific issues is by using\nthe __APPLE__ predefined macro.\n\nThe extra define _XOPEN_SOURCE_EXTENDED does only affect some headers\n(like the /usr/include/curses.h header) and can stay.\n\nFreeBSD 6 requires the __BSD_VISIBLE flag for fchmod(), IPPROTO_IPV6 and\nmore which is only properly set by if _POSIX_C_SOURCE\nisn't present. However, _POSIX_C_SOURCE is defined if _XOPEN_SOURCE is\ndefined and >=500.\n\nAs a solution, simply don't define _XOPEN_SOURCE for FreeBSD and continue\nwith its defaults.\n\nAuthor: Terje Sten Bjerkseth \nSigned-off-by: Rocco Rutte \nSigned-off-by: Marco Roeland \n---\n git-compat-util.h | 7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex bc296b3..6f46f36 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -11,7 +11,14 @@\n \n #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n \n+#if !defined(__APPLE__) && !defined(__FreeBSD)\n #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */\n+#else\n+\t\t\t/*\n+\t\t\t * On Darwin and FreeBSD defining _XOPEN_SOURCE always restricts available\n+\t\t\t * functions and symbols.\n+\t\t\t */\n+#endif\n #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n #define _GNU_SOURCE\n #define _BSD_SOURCE\n-- \n1.4.4.2.g81597-dirty\n"},{"id":"29938","messageId":"Pine.LNX.4.63.0612211231000.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6039","inReplyTo":"7vmz5ib8eu.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (stable), and Announcing GIT 1.4.4.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-21T11:38:17Z","receivedAt":"2006-12-21T11:38:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 20 Dec 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre (4):\n> make patch_delta() error cases a bit more verbose\n> make git a bit less cryptic on fetch errors\n> index-pack usage of mmap() is unacceptably slower on many OSes\n> other than Linux\n\nI assume that this line is indented manually, but ...\n\n> clarify some error messages wrt unknown object types\n> \n> Robert Fitzsimons (1):\n> gitweb: Show '...' links in \"summary\" view only if there are more items\n\nthis is not, in spite of being longer than 76 characters (Do I remember \ncorrectly that this supposed to be the maximum length for lines in \nemails?).\n\nFWIW, I hacked a half-serious patch to wrap the lines automatically:\n\n-- snipsnap --\n[FWOT] shortlog: wrap long lines\n\nIf a oneline is longer than 76 characters, wrap it and indent with\n9 instead of 6 spaces.\n\nFor the heck of it, assume UTF-8, and fall back to single-byte\nencodings when finding that it cannot be UTF-8. (Not that it makes\na difference if you stick to ASCII.)\n---\n builtin-shortlog.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++-\n t/t4201-shortlog.sh | 44 ++++++++++++++++++++++++++++++++++++\n 2 files changed, 104 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-shortlog.c b/builtin-shortlog.c\nindex edb4042..be5691e 100644\n--- a/builtin-shortlog.c\n+++ b/builtin-shortlog.c\n@@ -276,6 +276,64 @@ static void get_from_rev(struct rev_info *rev, struct path_list *list)\n \n }\n \n+/* Wrap the text, if necessary. */\n+static void print_oneline(const char *oneline, int indent, int indent2, int len)\n+{\n+\tint i, count, count_utf8, last_space = -1, assume_utf8 = 1;\n+\n+\tcount = count_utf8 = 0;\n+\n+\tfor (;;) {\n+\t\tunsigned char c = (unsigned char)oneline[count++];\n+\t\tif (!c || isspace(c)) {\n+\t\t\tint cur = indent\n+\t\t\t\t+ (assume_utf8 ? count_utf8 : count - 1);\n+\t\t\tif (cur < len || last_space < 0) {\n+//printf(\"(%d)\", cur);\n+\t\t\t\tif (last_space > 0)\n+\t\t\t\t\tputchar(' ');\n+\t\t\t\telse\n+\t\t\t\t\tfor (i = 0; i < indent; i++)\n+\t\t\t\t\t\tputchar(' ');\n+\t\t\t\tfor (i = last_space + 1; i < count - 1; i++)\n+\t\t\t\t\tputchar(oneline[i]);\n+\t\t\t\tif (!c) {\n+\t\t\t\t\tputchar('\\n');\n+\t\t\t\t\treturn;\n+\t\t\t\t}\n+\t\t\t\tlast_space = count - 1;\n+\t\t\t\tcount_utf8++;\n+\t\t\t} else {\n+\t\t\t\tputchar('\\n');\n+\t\t\t\tfor (oneline += last_space + 1;\n+\t\t\t\t\t\tisspace(*oneline); oneline++)\n+\t\t\t\t\t; /* do nothing */\n+\t\t\t\tindent = indent2;\n+\t\t\t\tlast_space = -1;\n+\t\t\t\tcount = count_utf8 = 0;\n+\t\t\t}\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (assume_utf8 && c > 0x7f) {\n+\t\t\tint multi_byte_count = 1;\n+\t\t\tif ((c & 0xe0) == 0xc0)\n+\t\t\t\tmulti_byte_count = 2;\n+\t\t\telse if ((c & 0xf0) == 0xe0)\n+\t\t\t\tmulti_byte_count = 3;\n+\t\t\telse if ((c & 0xf8) == 0xf0)\n+\t\t\t\tmulti_byte_count = 4;\n+\t\t\telse\n+\t\t\t\tassume_utf8 = 0;\n+\t\t\tfor (i = 0; i < multi_byte_count - 1; i++)\n+\t\t\t\tif (!oneline[count + i])\n+\t\t\t\t\tassume_utf8 = 0;\n+\t\t\tif (assume_utf8)\n+\t\t\t\tcount += multi_byte_count - 1;\n+\t\t}\n+\t\tcount_utf8++;\n+\t}\n+}\n+\n int cmd_shortlog(int argc, const char **argv, const char *prefix)\n {\n \tstruct rev_info rev;\n@@ -321,7 +379,8 @@ int cmd_shortlog(int argc, const char **argv, const char *prefix)\n \t\t} else {\n \t\t\tprintf(\"%s (%d):\\n\", list.items[i].path, onelines->nr);\n \t\t\tfor (j = onelines->nr - 1; j >= 0; j--)\n-\t\t\t\tprintf(\" %s\\n\", onelines->items[j].path);\n+\t\t\t\tprint_oneline(onelines->items[j].path,\n+\t\t\t\t\t6, 9, 76);\n \t\t\tprintf(\"\\n\");\n \t\t}\n \ndiff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh\nnew file mode 100644\nindex 0000000..86a2295\n--- /dev/null\n+++ b/t/t4201-shortlog.sh\n@@ -0,0 +1,44 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2006 Johannes E. Schindelin\n+#\n+\n+test_description='git-shortlog\n+'\n+\n+. ./test-lib.sh\n+\n+echo 1 > a1\n+git add a1\n+tree=$(git write-tree)\n+commit=$((echo \"Test\"; echo) | git commit-tree $tree)\n+git update-ref HEAD $commit \n+\n+echo 2 > a1\n+git commit -m \"This is a very, very long first line for the commit message to see if it is wrapped correctly\" a1\n+\n+# test if the wrapping is still valid when replacing all i's by treble clefs.\n+echo 3 > a1\n+git commit -m \"$(echo \"This is a very, very long first line for the commit message to see if it is wrapped correctly\" | sed \"s/i/1234/g\" | tr 1234 '\\360\\235\\204\\236')\" a1\n+\n+# now fsck up the utf8\n+echo 4 > a1\n+git commit -m \"$(echo \"This is a very, very long first line for the commit message to see if it is wrapped correctly\" | sed \"s/i/1234/g\" | tr 1234 '\\370\\235\\204\\236')\" a1\n+\n+git shortlog HEAD > out\n+\n+cat > expect << EOF\n+A U Thor (4):\n+ Test\n+ This is a very, very long first line for the commit message to see if\n+ it is wrapped correctly\n+ Th𝄞s 𝄞s a very, very long f𝄞rst l𝄞ne for the comm𝄞t message to see 𝄞f\n+ 𝄞t 𝄞s wrapped correctly\n+ Thø„žs ø„žs a very, very long fø„žrst lø„žne for the commø„žt\n+ message to see ø„žf ø„žt ø„žs wrapped correctly\n+\n+EOF\n+\n+test_expect_success 'shortlog wrapping' 'diff -u expect out'\n+\n+test_done\n-- \n1.4.4.3.g610c-dirty\n"},{"id":"29987","messageId":"7v64c492fv.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"20061221112835.GA7713@fiberbit.xs4all.nl","subject":"Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T00:52:52Z","receivedAt":"2006-12-22T00:52:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marco Roeland writes:\n\n> We want our symbols \"avilable\" so lets not use _XOPEN_SOURCE on Darwin!\n\nPersonally, I think hiding interfaces such as strXXX and memXXX\nbased on _XOPEN_SOURCE level is already a bug in the system\nheader implementation. The symbols that begin with str are\nalready reserved by the standard and I do not see any point\nin the system headers to try avoiding namespace contamination.\n\nBut we are not in the business of fixing the system headers.\n\n> The preferred way of checking specific Apple specific issues is by using\n> the __APPLE__ predefined macro.\n>\n> diff --git a/git-compat-util.h b/git-compat-util.h\n> index bc296b3..6f46f36 100644\n> --- a/git-compat-util.h\n> +++ b/git-compat-util.h\n> @@ -11,7 +11,14 @@\n> \n> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n> \n> +#if !defined(__APPLE__) && !defined(__FreeBSD)\n> #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */\n> +#else\n> +\t\t\t/*\n> +\t\t\t * On Darwin and FreeBSD defining _XOPEN_SOURCE always restricts available\n> +\t\t\t * functions and symbols.\n> +\t\t\t */\n> +#endif\n> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n> #define _GNU_SOURCE\n> #define _BSD_SOURCE\n\nTwo and half questions.\n\n #0.5 Have you checked the tip of 'master' that has Terje's\n patch? It was reported to work yesterday and that is what\n was committed already.\n\n #1 __APPLE__ vs __APPLE_CC__ is not something I can decide (I\n do not run a Mac). If MaxOS is derived from FreeBSD, does\n it by chance define __FreeBSD as well?\n\n #2 Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a\n Mac, but yours doesn't. Is there a reason that you would\n want '#define _XOPEN_SOURCE_EXTENDED 1'? Do both FreeBSD\n and Mac behave well with it defined?\n"},{"id":"29992","messageId":"20061222010403.GC14773@spearce.org","threadId":"6039","inReplyTo":"7v64c492fv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-22T01:04:03Z","receivedAt":"2006-12-22T01:04:03Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> #0.5 Have you checked the tip of 'master' that has Terje's\n> patch? It was reported to work yesterday and that is what\n> was committed already.\n\nOK, but that isn't applied in next for some reason. I'm still\ncarrying around my own version of Terje's patch. :-(\n \n> #1 __APPLE__ vs __APPLE_CC__ is not something I can decide (I\n> do not run a Mac). If MaxOS is derived from FreeBSD, does\n> it by chance define __FreeBSD as well?\n\n__FreeBSD doesn't work here on my Mac.\n\n-- \nShawn.\n"},{"id":"30018","messageId":"20061222065327.GA3773@peter.daprodeges.fqdn.th-h.de","threadId":"6039","inReplyTo":"7v64c492fv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting","fromName":"Rocco Rutte","fromEmail":"pdmef@gmx.net","sentAt":"2006-12-22T06:53:27Z","receivedAt":"2006-12-22T06:53:27Z","isPatch":true,"sender":{"key":"pdmef@gmx.net","avatar":null},"body":"Hi,\n\n* Junio C Hamano [06-12-21 16:52:52 -0800] wrote:\n>Marco Roeland writes:\n\n>> We want our symbols \"avilable\" so lets not use _XOPEN_SOURCE on Darwin!\n\n>Personally, I think hiding interfaces such as strXXX and memXXX\n>based on _XOPEN_SOURCE level is already a bug in the system\n>header implementation. The symbols that begin with str are\n>already reserved by the standard and I do not see any point\n>in the system headers to try avoiding namespace contamination.\n\nWell, it depends, I'd say. Different strXXX functions may be introduced \nby different versions of standards and with _POSIX_C_SOURCE one can, for \nexample, define to be compile for a specific standard version only.\n\n>Two and half questions.\n\n> #1 __APPLE__ vs __APPLE_CC__ is not something I can decide (I\n> do not run a Mac). If MaxOS is derived from FreeBSD, does\n> it by chance define __FreeBSD as well?\n\n> #2 Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a\n> Mac, but yours doesn't. Is there a reason that you would\n> want '#define _XOPEN_SOURCE_EXTENDED 1'? Do both FreeBSD\n> and Mac behave well with it defined?\n\nFirst of all, the combined patch posted is wrong since __FreeBSD doesn't \nwork on FreeBSD, but __FreeBSD__ does.\n\nSecond, a grep over the FreeBSD headers in /usr/include shows that \n_XOPEN_SOURCE_EXTENDED only affects 2 curses header files, so it's safe \nto exclude it, i.e. define it for FreeBSD.\n\n bye, Rocco\n-- \n:wq!\n"},{"id":"30020","messageId":"20061222075142.GA9595@fiberbit.xs4all.nl","threadId":"6039","inReplyTo":"7v64c492fv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-12-22T07:51:42Z","receivedAt":"2006-12-22T07:51:42Z","isPatch":true,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"On Thursday December 21st 2006 at 16:52 Junio C Hamano wrote:\n\n> Personally, I think hiding interfaces such as strXXX and memXXX\n> based on _XOPEN_SOURCE level is already a bug in the system\n> header implementation. The symbols that begin with str are\n> already reserved by the standard and I do not see any point\n> in the system headers to try avoiding namespace contamination.\n> \n> But we are not in the business of fixing the system headers.\n\n;-)\n\nPerhaps the idea behind this might be that it allows you to easier\ndevelop software that really only uses interfaces strictly defined in\nsome \"standards\" to be always available on compliant platforms. That's\nall I could think of why you ever would want to do it like this yes.\n\n> Two and half questions.\n> \n> #0.5 Have you checked the tip of 'master' that has Terje's\n> patch? It was reported to work yesterday and that is what\n> was committed already.\n\nFor some reason a normal \"pull\" didn't show this one here yet. But I can\nsee it by merging. The commit \"c902c9a\" that I now see from Terje does\nindeed work here. At any rate that one alone doesn't fix the (same)\nFreeBSD issue as reported by Rocco Rutte who sent in an almost identical\npatch but with the __FreeBSD__ define.\n\n> #1 __APPLE__ vs __APPLE_CC__ is not something I can decide (I\n> do not run a Mac). If MaxOS is derived from FreeBSD, does\n> it by chance define __FreeBSD as well?\n\nAs far as I know __APPLE__ is the preferred way of finding out we're\nrunning for a Darwin target. Someone mentioned that __APPLE_CC__ was not\nintroduced until Apple OS X 10.4. It's value here ('5367') is the build\nversion of the Apple gcc compiler, doesn't seem very standardized. The\n__APPLE__ macro is defined as '1'.\n\nUnfortunately no there is _not_ any \"BSD\" like macro defined here, so no\n__FreeBSD or something. And interesting enough we already know that\nOpenBSD specifically needs the _XOPEN_SOURCE define. Anyone out there\nwith a NetBSD box so we can fix that as well? ;-)\n\n> #2 Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a\n> Mac, but yours doesn't. Is there a reason that you would\n> want '#define _XOPEN_SOURCE_EXTENDED 1'? Do both FreeBSD\n> and Mac behave well with it defined?\n\nOn Apple compiling git works fine both with and without\n_XOPEN_SOURCES_EXTENDED. But looking in the headers, in contrast to the\n_XOPEN_SOURCE define which restricts functionality to some predefined\nset, the _XOPEN_SOURCES_EXTENDED only adds functionality and doesn't\nremove it. So I thought it might be best to keep as much symbols as\npossible to be the same for all platforms for future expandibility.\n\nProbably FreeBSD behaves the same with respect to\n_XOPEN_SOURCE_EXTENDED. Will check later today.\n\nI don't know if the \"Apple Public Source License\" allows me to put the\nDarwin system headers in a publicly accessable place, so I won't do\nthat, but if people are interested I can of course privately provide the\nsystem headers and predefined symbols for anyone interested.\n-- \nMarco Roeland\n"},{"id":"30028","messageId":"7v4pro5nsa.fsf@assigned-by-dhcp.cox.net","threadId":"6039","inReplyTo":"20061222075142.GA9595@fiberbit.xs4all.nl","subject":"Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T08:37:41Z","receivedAt":"2006-12-22T08:37:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marco Roeland writes:\n\n> On Thursday December 21st 2006 at 16:52 Junio C Hamano wrote:\n>\n>> Personally, I think hiding interfaces such as strXXX and memXXX\n>> based on _XOPEN_SOURCE level is already a bug in the system\n>> header implementation. The symbols that begin with str are\n>> already reserved by the standard and I do not see any point\n>> in the system headers to try avoiding namespace contamination.\n>> \n>> But we are not in the business of fixing the system headers.\n>\n> ;-)\n>\n> Perhaps the idea behind this might be that it allows you to easier\n> develop software that really only uses interfaces strictly defined in\n> some \"standards\" to be always available on compliant platforms. That's\n> all I could think of why you ever would want to do it like this yes.\n\n(offtopic) Yeah, but my point was that ANSI C reserves _all_\nsymbols that begin with str (\"Names reserved for expansion\"),\nnot just a specific set of functions like strcmp, strcpy, etc.,\nso if a program tries to be compliant with it, it cannot use,\nfor example, strncasecmp (was that the symbol we had trouble\nwith?) for its own purpose anyway -- which means the system\nheader implementation should not have to worry about namespace\npollution. I do not see any reason for them to hide\nstrncasecmp, for example.\n\n> On Apple compiling git works fine both with and without\n> _XOPEN_SOURCES_EXTENDED. But looking in the headers, in contrast to the\n> _XOPEN_SOURCE define which restricts functionality to some predefined\n> set, the _XOPEN_SOURCES_EXTENDED only adds functionality and doesn't\n> remove it. So I thought it might be best to keep as much symbols as\n> possible to be the same for all platforms for future expandibility.\n>\n> Probably FreeBSD behaves the same with respect to\n> _XOPEN_SOURCE_EXTENDED. Will check later today.\n\nOk, thanks.\n"},{"id":"30045","messageId":"20061222114722.GA11274@fiberbit.xs4all.nl","threadId":"6039","inReplyTo":"7v4pro5nsa.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-12-22T11:47:22Z","receivedAt":"2006-12-22T11:47:22Z","isPatch":true,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"On Friday December 22nd 2006 at 00:37 Junio C Hamano wrote:\n\n> (offtopic) Yeah, but my point was that ANSI C reserves _all_\n> symbols that begin with str (\"Names reserved for expansion\"),\n> not just a specific set of functions like strcmp, strcpy, etc.,\n> so if a program tries to be compliant with it, it cannot use,\n> for example, strncasecmp (was that the symbol we had trouble\n> with?) for its own purpose anyway -- which means the system\n> header implementation should not have to worry about namespace\n> pollution. I do not see any reason for them to hide\n> strncasecmp, for example.\n\n(ontopic for offtopic, that makes it still offtopic probably) I think\nthe intention from Apple might have been to provide a strict least\ncommon denominator environment for developing software that will run\non strictly standardized POSIX standards. Think of someone that has\nto develop a program on Darwin and that should also run on OS/400. If\nstrcasestr(3) isn't in the libraries there it might make some sense to\nnot make it available in this strict compatibility mode (expose no less\nbut also no more environment). A sort of combination of '-pedantic' with\n'-Werror' as it were. Note that I do not defend it, just trying to find\nsome sense of logic in it. ;-)\n\n> > On Apple compiling git works fine both with and without\n> > _XOPEN_SOURCES_EXTENDED. But looking in the headers, in contrast to the\n> > _XOPEN_SOURCE define which restricts functionality to some predefined\n> > set, the _XOPEN_SOURCES_EXTENDED only adds functionality and doesn't\n> > remove it. So I thought it might be best to keep as much symbols as\n> > possible to be the same for all platforms for future expandibility.\n> >\n> > Probably FreeBSD behaves the same with respect to\n> > _XOPEN_SOURCE_EXTENDED. Will check later today.\n> \n> Ok, thanks.\n\nChecking for compilation with FreeBSD as target should have the macro\n\"__FreeBSD__\" as value. No other value, as already pointed out by Rocco\nRutte.\n\nThe behaviour of _XOPEN_SOURCE_EXTENDED on FreeBSD is exactly like on\nApple. This means for git we can either include it or not, it won't make\na difference.\n\nThere is a subtle and interesting difference with respect to\nthe usage of _XOPEN_SOURCE on FreeBSD as compared to Darwin. The only\nthing that I see on FreeBSD is that it (indirectly through yet another\nmacro __XSI_VISIBLE) influences some functions (amongst which\nstrcasestr(3) in daemon.c) to be declared in the system header\n instead of in . The FreeBSD header claim that this\nshould be the POSIX behaviour for _XOPEN_SOURCE. As we do not include\n the compilation fails on FreeBSD.\n\nIn fact on FreeBSD the problem seems to be only that when _XOPEN_SOURCE\nis defined, than the macro __BSD_VISIBLE is unset or 0. Adding just\n\n#ifdef __FreeBSD__\n#define __BSD_VISIBLE 1\n#endif\n\nbefore setting _XOPEN_SOURCE in also results in git compiling perfectly\non FreeBSD. In that case for example automatically includes\n.\n\nSo on top of Terjes patch in \"master\":\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 41fa7f6..2303951 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -11,6 +11,10 @@\n \n #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n \n+#ifdef __FreeBSD__\n+#define __BSD_VISIBLE\t1\t/* needed in combination with _XOPEN_SOURCE */\n+#endif\n+\n #ifndef __APPLE_CC__\n #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */\n #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n-- \nMarco Roeland\n"},{"id":"30053","messageId":"20061222125505.GB3773@peter.daprodeges.fqdn.th-h.de","threadId":"6039","inReplyTo":"20061222114722.GA11274@fiberbit.xs4all.nl","subject":"Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting","fromName":"Rocco Rutte","fromEmail":"pdmef@gmx.net","sentAt":"2006-12-22T12:55:05Z","receivedAt":"2006-12-22T12:55:05Z","isPatch":true,"sender":{"key":"pdmef@gmx.net","avatar":null},"body":"Hi,\n\n* Marco Roeland [06-12-22 12:47:22 +0100] wrote:\n\n>In fact on FreeBSD the problem seems to be only that when _XOPEN_SOURCE\n>is defined, than the macro __BSD_VISIBLE is unset or 0. Adding just\n\n>#ifdef __FreeBSD__\n>#define __BSD_VISIBLE 1\n>#endif\n\nThe first patch I sent in did exactly that via -D__BSD_VISIBLE set in \nthe Makefile and Junio correctly complained that the __-prefix is meant \nto be for internal use only. I bet he'll say the same about this flavour \nof defining __BSD_VISIBLE. :)\n\nI was just too lazy to recursively go through the #define/#ifdef parts \nof header files to find why __BSD_VISIBLE is needed.\n\nSecond, in _XOPEN_SOURCE indirectly influences \n__BSD_VISIBLE through _POSIX_C_SOURCE. The latter is defined for values \nof >=500 for _XOPEN_SOURCE so that even\n\n #define _XOPEN_SOURCE 499\n\nworks fine on FreeBSD.\n\nI'm still in favour of simply adding '!defined(__FreeBSD__)' to \ngit-compat-util.h as soon as possible to push out a maintaince release \nthat at least compiles (on FreeBSD)...\n\n bye, Rocco\n-- \n:wq!\n"},{"id":"30055","messageId":"20061222131452.GB11274@fiberbit.xs4all.nl","threadId":"6039","inReplyTo":"20061222125505.GB3773@peter.daprodeges.fqdn.th-h.de","subject":"Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-12-22T13:14:52Z","receivedAt":"2006-12-22T13:14:52Z","isPatch":true,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"On Friday December 22nd 2006 at 12:55 Rocco Rutte wrote:\n\n> I'm still in favour of simply adding '!defined(__FreeBSD__)' to \n> git-compat-util.h as soon as possible to push out a maintaince release \n> that at least compiles (on FreeBSD)...\n\nAgreed. It's the more practical thing to do and Just Works (TM).\n\nPerhaps in the long run we could create platform specific header files\nto deal with whatever excentricities these provide or need, and include\nin git-compat-util.h things like for every candidate that needs it:\n\n#ifdef __CrappIX__\n#include \"compat/crappix.h\"\n#endif\n\nFor the _XOPEN_SOURCE specific things it might also be better to reverse\nthe logic, so not exclude it for a number of platforms but only include\nit for the specific platforms that seem to need it.\n\nSo, again on top of Terjes patch in \"master\":\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 41fa7f6..c7930d2 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -11,7 +11,7 @@\n \n #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))\n \n-#ifndef __APPLE_CC__\n+#if !defined(__APPLE__) && !defined(__FreeBSD__)\n #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */\n #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */\n #endif\n-- \nMarco Roeland\n"},{"id":"30754","messageId":"459BCAF2.1080002@op5.se","threadId":"6039","inReplyTo":"7vtzzq3wo6.fsf@assigned-by-dhcp.cox.net","subject":"Re: [BUG] daemon.c blows up on OSX","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-03T15:25:38Z","receivedAt":"2007-01-03T15:25:38Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> Does everybody use Apple CC on OSX? Is the symbol defined even\n> with GCC? Or Gcc fixes headers well enough and makes this a\n> non-issue?\n> \n\nJust for future reference\n\nhttp://predef.sourceforge.net/preos.html\n\nholds a pretty complete list of identifying macros for more kinds of \nsystems than I've had the questionable privilege of having to work with. \nI've used it pretty extensively when trying to write portable code, \nsince I too have a hard time liking autoconf and friends.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"}]}