Trying to get GIT running on SCO OpenServer

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.

Hi,

On Wed, 23 Jan 2008, Aidan Van Dyk wrote:

Hehe.  They say: "de mortuis nil nisi bene".

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I think the "convention" is to use BROKEN_SNPRINTF=UnfortunatelyYes ;-)

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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.

Junio C Hamano wrote:

That's what va_copy() is for.

	-hpa

"H. Peter Anvin" <hpa@zytor.com> writes:

Yes.  See 4bf53833dbca666f61b5177977e96d453527db20 ;-)

On Wed, 23 Jan 2008, H. Peter Anvin wrote:

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

On Jan 23, 2008, at 6:50 PM, Linus Torvalds wrote:

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/

On Wed, 23 Jan 2008, Luke Lu wrote:

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

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:    <no source text available>
	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.