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.



-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

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

Johannes Schindelin [off-list ref] 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

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.

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.