Trying to get GIT running on SCO OpenServer

Trying to get GIT running on SCO OpenServer

[Aidan Van Dyk]

[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]


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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Trying to get GIT running on SCO OpenServer

[Johannes Schindelin]

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

Re: Trying to get GIT running on SCO OpenServer

[Jakub Narebski]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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

Re: Trying to get GIT running on SCO OpenServer

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

Re: Trying to get GIT running on SCO OpenServer

[H. Peter Anvin]

Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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

Re: Trying to get GIT running on SCO OpenServer

[Junio C Hamano]

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

> Junio C Hamano wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 ;-)

Re: Trying to get GIT running on SCO OpenServer

[Linus Torvalds]

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

Re: Trying to get GIT running on SCO OpenServer

[Luke Lu]

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/

Re: Trying to get GIT running on SCO OpenServer

[Linus Torvalds]

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

Re: Trying to get GIT running on SCO OpenServer

[Aidan Van Dyk]

[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]