# Trying to get GIT running on SCO OpenServer 10 messages from 2008-01-23 to 2008-01-24. Participants: Aidan Van Dyk, Johannes Schindelin, Jakub Narebski, Junio C Hamano, H. Peter Anvin, Linus Torvalds, Luke Lu. Thread: https://gitlist.dev/t/11714 ## Aidan Van Dyk, 2008-01-23 21:26 Subject: Trying to get GIT running on SCO OpenServer Message-ID: <20080123212613.GN2230@yugib.highrise.ca> URL: https://gitlist.dev/e/20080123212613.GN2230%40yugib.highrise.ca ``` I know - openserver, yuch, bla bla bla... Not my choice, but sometimes we have to do things we don't like... But, I've come across this in strbuf.c: va_start(ap, fmt); len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap); va_end(ap); if (len < 0) die("your vsnprintf is broken"); Now, that would seem to be the interpretation of vsnprintf I'm familiar with too, but I read this in the SCO vsnprintf man page: snprintf (vsnprintf) behaves like sprintf (vsprintf), except that no more than maxsize characters are placed into the array, including the terminating null character. If more than maxsize characters were requested, the output array will contain exactly maxsize characters, with a null character being the last (when maxsize is nonzero); a negative value is returned. [...] vfprintf(S-osr5), vprintf(S-osr5), and vsprintf(S-osr5) are conformant with : X/Open Portability Guide, Issue 3, 1989 ; and ANSI X3.159-1989 Programming Language -- C . I guess this means that git is designed to not work on on systems such as SCO that have what we (myself included) consider "broken" vsnprintf. Is there any interest in trying to get strbuf to work with such broken vsnprintf implementations? I've got a couple of other small patches to make it "compile" on OpenServer, but if this is too brain-dead to be worth supporting, there is no point in cluttering things up more for compatibility which can't really be used anyways. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. ``` ## Johannes Schindelin, 2008-01-23 23:48 Subject: Re: Trying to get GIT running on SCO OpenServer Message-ID: URL: https://gitlist.dev/e/alpine.LSU.1.00.0801232346010.5731%40racer.site In-Reply-To: <20080123212613.GN2230@yugib.highrise.ca> ``` Hi, On Wed, 23 Jan 2008, Aidan Van Dyk wrote: > I know - openserver, yuch, bla bla bla... Not my choice, but sometimes > we have to do things we don't like... Hehe. They say: "de mortuis nil nisi bene". > snprintf (vsnprintf) behaves like sprintf (vsprintf), except that no > more than maxsize characters are placed into the array, including the > terminating null character. If more than maxsize characters were > requested, the output array will contain exactly maxsize characters, > with a null character being the last (when maxsize is nonzero); a > negative value is returned. FWIW we had the same problem in MinGW, and Hannes Sixt solved it: http://repo.or.cz/w/git/mingw/j6t.git?a=commitdiff;h=b8e84a68f01a2386b2071e1bdc8e24de809a3f6d That might give you an idea how to solve the issue. Maybe you even make a git patch out of it? With a Makefile variable BROKEN_SNPRINTF=YesPlease, maybe? Hth, Dscho ``` ## Jakub Narebski, 2008-01-24 00:17 Subject: Re: Trying to get GIT running on SCO OpenServer Message-ID: URL: https://gitlist.dev/e/m3bq7ckrh7.fsf%40roke.D-201 In-Reply-To: ``` Johannes Schindelin writes: > That might give you an idea how to solve the issue. Maybe you even make a > git patch out of it? With a Makefile variable BROKEN_SNPRINTF=YesPlease, > maybe? I think the "convention" is to use BROKEN_SNPRINTF=UnfortunatelyYes ;-) -- Jakub Narebski Poland ShadeHawk on #git ``` ## Junio C Hamano, 2008-01-24 00:25 Subject: Re: Trying to get GIT running on SCO OpenServer Message-ID: <7vsl0oax42.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vsl0oax42.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Johannes Schindelin writes: > FWIW we had the same problem in MinGW, and Hannes Sixt solved it: > > http://repo.or.cz/w/git/mingw/j6t.git?a=commitdiff;h=b8e84a68f01a2386b2071e1bdc8e24de809a3f6d > > That might give you an idea how to solve the issue. Maybe you even make a > git patch out of it? With a Makefile variable BROKEN_SNPRINTF=YesPlease, > maybe? Hmmm. Looking at that change makes me wonder if that solution is Kosher. The value of the va_list you pass to vsnprintf() is unspecified after the call. It may be Ok as mingw-only "compatibility wrapper", but I think you have to be a bit careful. It is not a general solution for any BROKEN_SNPRINTF. ``` ## H. Peter Anvin, 2008-01-24 02:33 Subject: Re: Trying to get GIT running on SCO OpenServer Message-ID: <4797F902.4000104@zytor.com> URL: https://gitlist.dev/e/4797F902.4000104%40zytor.com In-Reply-To: <7vsl0oax42.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano wrote: > Johannes Schindelin writes: > >> FWIW we had the same problem in MinGW, and Hannes Sixt solved it: >> >> http://repo.or.cz/w/git/mingw/j6t.git?a=commitdiff;h=b8e84a68f01a2386b2071e1bdc8e24de809a3f6d >> >> That might give you an idea how to solve the issue. Maybe you even make a >> git patch out of it? With a Makefile variable BROKEN_SNPRINTF=YesPlease, >> maybe? > > Hmmm. Looking at that change makes me wonder if that solution > is Kosher. The value of the va_list you pass to vsnprintf() is > unspecified after the call. > > It may be Ok as mingw-only "compatibility wrapper", but I think > you have to be a bit careful. It is not a general solution for > any BROKEN_SNPRINTF. > That's what va_copy() is for. -hpa ``` ## Junio C Hamano, 2008-01-24 02:48 Subject: Re: Trying to get GIT running on SCO OpenServer Message-ID: <7vodbcaqh2.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vodbcaqh2.fsf%40gitster.siamese.dyndns.org In-Reply-To: <4797F902.4000104@zytor.com> ``` "H. Peter Anvin" writes: > Junio C Hamano wrote: >> Johannes Schindelin writes: >> >>> FWIW we had the same problem in MinGW, and Hannes Sixt solved it: >>> >>> http://repo.or.cz/w/git/mingw/j6t.git?a=commitdiff;h=b8e84a68f01a2386b2071e1bdc8e24de809a3f6d >>> >>> That might give you an idea how to solve the issue. Maybe you even >>> make a git patch out of it? With a Makefile variable >>> BROKEN_SNPRINTF=YesPlease, maybe? >> >> Hmmm. Looking at that change makes me wonder if that solution >> is Kosher. The value of the va_list you pass to vsnprintf() is >> unspecified after the call. >> >> It may be Ok as mingw-only "compatibility wrapper", but I think >> you have to be a bit careful. It is not a general solution for >> any BROKEN_SNPRINTF. > > That's what va_copy() is for. Yes. See 4bf53833dbca666f61b5177977e96d453527db20 ;-) ``` ## Linus Torvalds, 2008-01-24 02:50 Subject: Re: Trying to get GIT running on SCO OpenServer Message-ID: URL: https://gitlist.dev/e/alpine.LFD.1.00.0801231846540.2803%40woody.linux-foundation.org In-Reply-To: <4797F902.4000104@zytor.com> ``` On Wed, 23 Jan 2008, H. Peter Anvin wrote: > > That's what va_copy() is for. Well, anybody who has such an old setup that they have a broken vsnprintf, I'd expect they don't have va_copy() either. It's C99, I think (although there were obviously implementations of it before that). Linus ``` ## Luke Lu, 2008-01-24 03:01 Subject: Re: Trying to get GIT running on SCO OpenServer Message-ID: <3213B93E-42FF-4D63-A3A4-BD742630CEA1@vicaya.com> URL: https://gitlist.dev/e/3213B93E-42FF-4D63-A3A4-BD742630CEA1%40vicaya.com In-Reply-To: ``` On Jan 23, 2008, at 6:50 PM, Linus Torvalds wrote: > > On Wed, 23 Jan 2008, H. Peter Anvin wrote: >> >> That's what va_copy() is for. > > Well, anybody who has such an old setup that they have a broken > vsnprintf, > I'd expect they don't have va_copy() either. It's C99, I think > (although > there were obviously implementations of it before that). I wonder what's the downside of just using a native format implementation like the one in Vstr[1] or bstring[2]? strbuf_addf would be faster and immune to the buggy/outdated host *sprintf implementations. __Luke [1]: http://www.and.org/vstr/ [2]: http://bstring.sourceforge.net/ ``` ## Linus Torvalds, 2008-01-24 03:19 Subject: Re: Trying to get GIT running on SCO OpenServer Message-ID: URL: https://gitlist.dev/e/alpine.LFD.1.00.0801231912230.2803%40woody.linux-foundation.org In-Reply-To: <3213B93E-42FF-4D63-A3A4-BD742630CEA1@vicaya.com> ``` On Wed, 23 Jan 2008, Luke Lu wrote: > > I wonder what's the downside of just using a native format implementation like > the one in Vstr[1] or bstring[2]? I'd suggest taking the kernel vsnprintf() instead. It has the standard interface (no support for FP, but we don't care) so it should be pretty easy to just plug in, and it doesn't reaquire much of the environment (just a 64-bit divide&modulus-by-100000). Linus ``` ## Aidan Van Dyk, 2008-01-24 16:23 Subject: Re: Trying to get GIT running on SCO OpenServer Message-ID: <20080124162338.GC17244@yugib.highrise.ca> URL: https://gitlist.dev/e/20080124162338.GC17244%40yugib.highrise.ca In-Reply-To: <20080123212613.GN2230@yugib.highrise.ca> ``` OK, piling hack upon hack to get things to work, I've got 4 tests that don't pass: -rwxr-xr-x 1 aidan group 5733 Jan 23 20:57 t/t5302-pack-index.sh -rwxr-xr-x 1 aidan group 4204 Dec 4 15:21 t/t5400-send-pack.sh -rwxr-xr-x 1 aidan group 4321 Dec 4 15:21 t/t7003-filter-branch.sh -rwxr-xr-x 1 aidan group 16846 Jan 23 20:57 t/t9500-gitweb-standalone-no-errors.sh git-pack-objects is segfaulting: ~/software/git.git/t/trash$ git-pack-objects test < obj-list Counting objects: 102, done. Compressing objects: 100% (101/101), done. Segmentation Fault Stack trace: SIGNALED 11 (segv code[SEGV_MAPERR] address[0xbff68008]) in p1 184: debug> stack Stack Trace for p1, Program git-pack-objec *[0] find_packed_object(presumed: 0, 0, 0xc) [�\@builtin-pack-objects.c@184] [1] write_one(presumed: 0xc, 0, 0) [�\@builtin-pack-objects.c@512] [2] write_pack_file(presumed: 0x8049364, 0, 0) [�\@builtin-pack-objects.c@628] [3] cmd_pack_objects() [�\@builtin-pack-objects.c@2245] Before I dig too deeply, does that look familiar to anyone? Just FYI, my current stack of hacks is: HACK: BROKEN_FOPEN HACK: BROKEN_VSNPRINTF HACK: strtoul NO_RSYNC to avoid mkdtemp An interesting one is the strtoul HACK: diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c index 1e51865..2c2e187 100644 --- a/builtin-unpack-objects.c +++ b/builtin-unpack-objects.c @@ -368,7 +368,11 @@ int cmd_unpack_objects(int argc, const char **argv, const char *prefix) hdr->hdr_version = htonl(strtoul(arg + 14, &c, 10)); if (*c != ',') die("bad %s", arg); - hdr->hdr_entries = htonl(strtoul(c + 1, &c, 10)); +{ /* Another ugly SCO hack */ +char*d; + hdr->hdr_entries = htonl(strtoul(c + 1, &d, 10)); +c = d; +} if (*c) die("bad %s", arg); len = sizeof(*hdr); Is this just a *completely* broken compiler? With out this hack, "c" is set to something farther ahead then the null at the end of the "--pack-objects=2,10", and the if (*c) test obviously fails (and the value read by the strtoul isn't correct either). I've verified that the c *is* ",10" before entering that line... and I can't see any reason why that wouldn't "just work", but hey, this is SCO. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. ```