Path: utzoo!attcan!uunet!mcsun!ukc!pyrltd!root44!kieron
From: kieron@root.co.uk (Kieron Drake)
Newsgroups: comp.unix.aux
Subject: Re: XmacII color name lookup problems
Message-ID: <2476@root44.co.uk>
Date: 15 Oct 90 14:33:55 GMT
References: <2463@root44.co.uk> <1990Oct11.145627@springer.Apple.COM>
Organization: UniSoft Ltd., London, England
Lines: 83
To: peters@apple.apple.com, xbugs@expo.lcs.mit.edu

In comp.unix.aux you write:

>In article <2463@root44.co.uk>, kieron@root.co.uk (Kieron Drake) writes:
>|> 
>|> DESCRIPTION:
>|> 
	[ stuff about an extra indirection being required on fetch()... ]

>Actually the man page is wrong, /usr/include/dbm.h and the source for
>fetch in our dbm.c agree:

>datum
>fetch(key)
>        datum key;
>{
>...
>}

>As for your problem, I think the fault is in rgb.c where the compiler
>errs :-( . To wit --
	[ details of cc error and fix to rgb.c .... ]

>Steve Peters
>X Project Leader
>Apple Computer, Inc.
>peters@apple.apple.com

Steve, you're absolutely right. Mea culpa. On closer examination I had
two different problems and a slight bit of forgetfulness to contend
with:

	1)	With cc there is indeed no need for the extra inderction as
		the code generated in the two cases is the same. e.g.


		foo() {
			struct _bar {char *a,*b;} d, fetch(), *fetchp();

			d = fetch(d);
			d = *fetch(d); /* same code for cc, different for gcc */
		}

		In both assignements into d the same code is generated for
		the move:

			mov.l (%a0)+,(%a1)+
			mov.l (%a0),(%a1)

		as a0 is expected to point at the structure in both cases.

		However the database was junk because of the rgb bug that
		Steve pointed out.

	2)	When using gcc, for the server/showrgb or the example above,
		different codee is generated with the first (small) result being
		expected in d0/d1 and the second expected as a pointer in a0.
		Thus with gcc an extra indirection, as erroneously suggested
		by the man page, will allow the dbm libraries and the
		fetch()-using routines to work together if the struct-return
		info in the machine description doesn't match what A/UX cc
		does!

		Another solution is to fix the machine description for
		gcc-A/UX so that structure results are pointed to by a0
		and all is sweetness and light. I've since done this here.
		Then the #ifdef macII stuff is unnecessary.

Why did it work then if the database was junk? Well, this is where I
screwed up badly. In the process of isolating the problem I had
used a Sun-3 produced rgb database and forgotten that I'd copied it across!

Time for the hair shirt! Thanks for pointing out the real problem Steve.
I hope that this explanation helps other people.


	kieron


-- 
	Kieron Drake
MAIL:	kieron@root.co.uk
SNAIL:	UniSoft Ltd, Saunderson House, Hayne Street, London EC1A 9HH
PHONE:	+44 71 315 6637 (direct) +44 71 315 6600 (switchboard)