{"thread":{"id":"11714","subject":"Trying to get GIT running on SCO OpenServer","startedAt":"2008-01-23T21:26:13Z","lastAt":"2008-01-24T16:23:38Z","messageCount":10,"participants":["Aidan Van Dyk","Johannes Schindelin","Jakub Narebski","Junio C Hamano","H. Peter Anvin","Linus Torvalds","Luke Lu"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"66431","messageId":"20080123212613.GN2230@yugib.highrise.ca","threadId":"11714","inReplyTo":null,"subject":"Trying to get GIT running on SCO OpenServer","fromName":"Aidan Van Dyk","fromEmail":"aidan@highrise.ca","sentAt":"2008-01-23T21:26:13Z","receivedAt":"2008-01-23T21:26:13Z","isPatch":false,"sender":{"key":"aidan@highrise.ca","avatar":"https://gravatar.com/avatar/853c50d90cce753dc1c390fdc6cbed558f5f969bd43fa4f5cb0118d8f71316f6?d=mp&s=160"},"body":"\nI know - openserver, yuch, bla bla bla... Not my choice, but sometimes\nwe have to do things we don't like...\n\nBut, I've come across this in strbuf.c:\n        va_start(ap, fmt);\n        len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);\n        va_end(ap);\n        if (len < 0)\n                die(\"your vsnprintf is broken\");\n\nNow, that would seem to be the interpretation of vsnprintf I'm familiar\nwith too, but I read this in the SCO vsnprintf man page:\n\n   snprintf (vsnprintf) behaves like sprintf (vsprintf), except that no\n   more than maxsize characters are placed into the array, including the\n   terminating null character. If more than maxsize characters were\n   requested, the output array will contain exactly maxsize characters,\n   with a null character being the last (when maxsize is nonzero); a\n   negative value is returned.\n\n   [...] \n\n   vfprintf(S-osr5), vprintf(S-osr5), and vsprintf(S-osr5) are conformant\n   with :\n\n   X/Open Portability Guide, Issue 3, 1989 ;\n   and ANSI X3.159-1989 Programming Language -- C .\n\nI guess this means that git is designed to not work on on systems such\nas SCO that have what we (myself included) consider \"broken\" vsnprintf.\n\nIs there any interest in trying to get strbuf to work with such broken\nvsnprintf implementations?\n\nI've got a couple of other small patches to make it \"compile\" on\nOpenServer, but if this is too brain-dead to be worth supporting, there\nis no point in cluttering things up more for compatibility which can't\nreally be used anyways.\n\na.\n\n\n\n-- \nAidan Van Dyk                                             Create like a god,\naidan@highrise.ca                                       command like a king,\nhttp://www.highrise.ca/                                   work like a slave.\n"},{"id":"66434","messageId":"alpine.LSU.1.00.0801232346010.5731@racer.site","threadId":"11714","inReplyTo":"20080123212613.GN2230@yugib.highrise.ca","subject":"Re: Trying to get GIT running on SCO OpenServer","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-01-23T23:48:16Z","receivedAt":"2008-01-23T23:48:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jan 2008, Aidan Van Dyk wrote:\n\n> I know - openserver, yuch, bla bla bla... Not my choice, but sometimes \n> we have to do things we don't like...\n\nHehe.  They say: \"de mortuis nil nisi bene\".\n\n>    snprintf (vsnprintf) behaves like sprintf (vsprintf), except that no\n>    more than maxsize characters are placed into the array, including the\n>    terminating null character. If more than maxsize characters were\n>    requested, the output array will contain exactly maxsize characters,\n>    with a null character being the last (when maxsize is nonzero); a\n>    negative value is returned.\n\nFWIW we had the same problem in MinGW, and Hannes Sixt solved it:\n\nhttp://repo.or.cz/w/git/mingw/j6t.git?a=commitdiff;h=b8e84a68f01a2386b2071e1bdc8e24de809a3f6d\n\nThat might give you an idea how to solve the issue.  Maybe you even make a \ngit patch out of it?  With a Makefile variable BROKEN_SNPRINTF=YesPlease, \nmaybe?\n\nHth,\nDscho\n"},{"id":"66436","messageId":"m3bq7ckrh7.fsf@roke.D-201","threadId":"11714","inReplyTo":"alpine.LSU.1.00.0801232346010.5731@racer.site","subject":"Re: Trying to get GIT running on SCO OpenServer","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-01-24T00:17:16Z","receivedAt":"2008-01-24T00:17:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> That might give you an idea how to solve the issue.  Maybe you even make a \n> git patch out of it?  With a Makefile variable BROKEN_SNPRINTF=YesPlease, \n> maybe?\n\nI think the \"convention\" is to use BROKEN_SNPRINTF=UnfortunatelyYes ;-)\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"66437","messageId":"7vsl0oax42.fsf@gitster.siamese.dyndns.org","threadId":"11714","inReplyTo":"alpine.LSU.1.00.0801232346010.5731@racer.site","subject":"Re: Trying to get GIT running on SCO OpenServer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-24T00:25:01Z","receivedAt":"2008-01-24T00:25:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> FWIW we had the same problem in MinGW, and Hannes Sixt solved it:\n>\n> http://repo.or.cz/w/git/mingw/j6t.git?a=commitdiff;h=b8e84a68f01a2386b2071e1bdc8e24de809a3f6d\n>\n> That might give you an idea how to solve the issue.  Maybe you even make a \n> git patch out of it?  With a Makefile variable BROKEN_SNPRINTF=YesPlease, \n> maybe?\n\nHmmm.  Looking at that change makes me wonder if that solution\nis Kosher.  The value of the va_list you pass to vsnprintf() is\nunspecified after the call.\n\nIt may be Ok as mingw-only \"compatibility wrapper\", but I think\nyou have to be a bit careful.  It is not a general solution for\nany BROKEN_SNPRINTF.\n"},{"id":"66439","messageId":"4797F902.4000104@zytor.com","threadId":"11714","inReplyTo":"7vsl0oax42.fsf@gitster.siamese.dyndns.org","subject":"Re: Trying to get GIT running on SCO OpenServer","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-01-24T02:33:38Z","receivedAt":"2008-01-24T02:33:38Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n>> FWIW we had the same problem in MinGW, and Hannes Sixt solved it:\n>>\n>> http://repo.or.cz/w/git/mingw/j6t.git?a=commitdiff;h=b8e84a68f01a2386b2071e1bdc8e24de809a3f6d\n>>\n>> That might give you an idea how to solve the issue.  Maybe you even make a \n>> git patch out of it?  With a Makefile variable BROKEN_SNPRINTF=YesPlease, \n>> maybe?\n> \n> Hmmm.  Looking at that change makes me wonder if that solution\n> is Kosher.  The value of the va_list you pass to vsnprintf() is\n> unspecified after the call.\n> \n> It may be Ok as mingw-only \"compatibility wrapper\", but I think\n> you have to be a bit careful.  It is not a general solution for\n> any BROKEN_SNPRINTF.\n> \n\nThat's what va_copy() is for.\n\n\t-hpa\n"},{"id":"66440","messageId":"7vodbcaqh2.fsf@gitster.siamese.dyndns.org","threadId":"11714","inReplyTo":"4797F902.4000104@zytor.com","subject":"Re: Trying to get GIT running on SCO OpenServer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-24T02:48:25Z","receivedAt":"2008-01-24T02:48:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" <hpa@zytor.com> writes:\n\n> Junio C Hamano wrote:\n>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>>\n>>> FWIW we had the same problem in MinGW, and Hannes Sixt solved it:\n>>>\n>>> http://repo.or.cz/w/git/mingw/j6t.git?a=commitdiff;h=b8e84a68f01a2386b2071e1bdc8e24de809a3f6d\n>>>\n>>> That might give you an idea how to solve the issue.  Maybe you even\n>>> make a git patch out of it?  With a Makefile variable\n>>> BROKEN_SNPRINTF=YesPlease, maybe?\n>>\n>> Hmmm.  Looking at that change makes me wonder if that solution\n>> is Kosher.  The value of the va_list you pass to vsnprintf() is\n>> unspecified after the call.\n>>\n>> It may be Ok as mingw-only \"compatibility wrapper\", but I think\n>> you have to be a bit careful.  It is not a general solution for\n>> any BROKEN_SNPRINTF.\n>\n> That's what va_copy() is for.\n\nYes.  See 4bf53833dbca666f61b5177977e96d453527db20 ;-)\n"},{"id":"66441","messageId":"alpine.LFD.1.00.0801231846540.2803@woody.linux-foundation.org","threadId":"11714","inReplyTo":"4797F902.4000104@zytor.com","subject":"Re: Trying to get GIT running on SCO OpenServer","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-01-24T02:50:33Z","receivedAt":"2008-01-24T02:50:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 23 Jan 2008, H. Peter Anvin wrote:\n> \n> That's what va_copy() is for.\n\nWell, anybody who has such an old setup that they have a broken vsnprintf, \nI'd expect they don't have va_copy() either. It's C99, I think (although \nthere were obviously implementations of it before that).\n\n\t\t\tLinus\n"},{"id":"66442","messageId":"3213B93E-42FF-4D63-A3A4-BD742630CEA1@vicaya.com","threadId":"11714","inReplyTo":"alpine.LFD.1.00.0801231846540.2803@woody.linux-foundation.org","subject":"Re: Trying to get GIT running on SCO OpenServer","fromName":"Luke Lu","fromEmail":"git@vicaya.com","sentAt":"2008-01-24T03:01:50Z","receivedAt":"2008-01-24T03:01:50Z","isPatch":false,"sender":{"key":"git@vicaya.com","avatar":null},"body":"On Jan 23, 2008, at 6:50 PM, Linus Torvalds wrote:\n>\n> On Wed, 23 Jan 2008, H. Peter Anvin wrote:\n>>\n>> That's what va_copy() is for.\n>\n> Well, anybody who has such an old setup that they have a broken  \n> vsnprintf,\n> I'd expect they don't have va_copy() either. It's C99, I think  \n> (although\n> there were obviously implementations of it before that).\n\nI wonder what's the downside of just using a native format  \nimplementation like the one in Vstr[1] or bstring[2]?\n\nstrbuf_addf would be faster and immune to the buggy/outdated host  \n*sprintf implementations.\n\n__Luke\n\n[1]: http://www.and.org/vstr/\n[2]: http://bstring.sourceforge.net/\n"},{"id":"66444","messageId":"alpine.LFD.1.00.0801231912230.2803@woody.linux-foundation.org","threadId":"11714","inReplyTo":"3213B93E-42FF-4D63-A3A4-BD742630CEA1@vicaya.com","subject":"Re: Trying to get GIT running on SCO OpenServer","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-01-24T03:19:40Z","receivedAt":"2008-01-24T03:19:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 23 Jan 2008, Luke Lu wrote:\n> \n> I wonder what's the downside of just using a native format implementation like\n> the one in Vstr[1] or bstring[2]?\n\nI'd suggest taking the kernel vsnprintf() instead. It has the standard \ninterface (no support for FP, but we don't care) so it should be pretty \neasy to just plug in, and it doesn't reaquire much of the environment \n(just a 64-bit divide&modulus-by-100000).\n\n\t\t\tLinus\n"},{"id":"66488","messageId":"20080124162338.GC17244@yugib.highrise.ca","threadId":"11714","inReplyTo":"20080123212613.GN2230@yugib.highrise.ca","subject":"Re: Trying to get GIT running on SCO OpenServer","fromName":"Aidan Van Dyk","fromEmail":"aidan@highrise.ca","sentAt":"2008-01-24T16:23:38Z","receivedAt":"2008-01-24T16:23:38Z","isPatch":false,"sender":{"key":"aidan@highrise.ca","avatar":"https://gravatar.com/avatar/853c50d90cce753dc1c390fdc6cbed558f5f969bd43fa4f5cb0118d8f71316f6?d=mp&s=160"},"body":"OK, piling hack upon hack to get things to work, I've got 4 tests that\ndon't pass:\n\t-rwxr-xr-x 1 aidan group  5733 Jan 23 20:57 t/t5302-pack-index.sh\n\t-rwxr-xr-x 1 aidan group  4204 Dec  4 15:21 t/t5400-send-pack.sh\n\t-rwxr-xr-x 1 aidan group  4321 Dec  4 15:21 t/t7003-filter-branch.sh\n\t-rwxr-xr-x 1 aidan group 16846 Jan 23 20:57 t/t9500-gitweb-standalone-no-errors.sh\n\ngit-pack-objects is segfaulting:\n\t~/software/git.git/t/trash$ git-pack-objects test < obj-list\n\tCounting objects: 102, done.\n\tCompressing objects: 100% (101/101), done.\n\tSegmentation Fault\n\nStack trace:\n\tSIGNALED 11 (segv code[SEGV_MAPERR] address[0xbff68008]) in p1\n\t184:    <no source text available>\n\tdebug> stack\n\tStack Trace for p1, Program git-pack-objec\n\t*[0] find_packed_object(presumed: 0, 0, 0xc)    [�\\@builtin-pack-objects.c@184]\n\t [1] write_one(presumed: 0xc, 0, 0)     [�\\@builtin-pack-objects.c@512]\n\t [2] write_pack_file(presumed: 0x8049364, 0, 0) [�\\@builtin-pack-objects.c@628]\n\t [3] cmd_pack_objects() [�\\@builtin-pack-objects.c@2245]\n\nBefore I dig too deeply, does that look familiar to anyone?\n\nJust FYI, my current stack of hacks is:\n\tHACK: BROKEN_FOPEN\n\tHACK: BROKEN_VSNPRINTF\n\tHACK: strtoul\n\tNO_RSYNC to avoid mkdtemp\n\nAn interesting one is the strtoul HACK:\n\tdiff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c\n\tindex 1e51865..2c2e187 100644\n\t--- a/builtin-unpack-objects.c\n\t+++ b/builtin-unpack-objects.c\n\t@@ -368,7 +368,11 @@ int cmd_unpack_objects(int argc, const char **argv, const char *prefix)\n\t\t\t\t\thdr->hdr_version = htonl(strtoul(arg + 14, &c, 10));\n\t\t\t\t\tif (*c != ',')\n\t\t\t\t\t\tdie(\"bad %s\", arg);\n\t-                               hdr->hdr_entries = htonl(strtoul(c + 1, &c, 10));\n\t+{      /* Another ugly SCO hack */\n\t+char*d;\n\t+                               hdr->hdr_entries = htonl(strtoul(c + 1, &d, 10));\n\t+c = d;\n\t+}\n\t\t\t\t\tif (*c)\n\t\t\t\t\t\tdie(\"bad %s\", arg);\n\t\t\t\t\tlen = sizeof(*hdr);\n\nIs this just a *completely* broken compiler?  With out this hack,\n\"c\" is set to something farther ahead then the null at the end of the\n\"--pack-objects=2,10\", and the if (*c) test obviously fails (and the\nvalue read by the strtoul isn't correct either).\n\nI've verified that the c *is* \",10\" before entering that line... and I\ncan't see any reason why that wouldn't \"just work\", but hey, this is\nSCO.\n\na.\n\n-- \nAidan Van Dyk                                             Create like a god,\naidan@highrise.ca                                       command like a king,\nhttp://www.highrise.ca/                                   work like a slave.\n"}]}