kieron@root.co.uk (Kieron Drake) (10/10/90)
[being sent to both xbugs and comp.unix.aux]
X Window System Bug Report
xbugs@expo.lcs.mit.edu
VERSION:
R4
CLIENT MACHINE and OPERATING SYSTEM:
MacIIfx, A/UX 2.0 Beta 15
DISPLAY TYPE:
N/A
WINDOW MANAGER:
N/A
AREA:
Server: OsLookupColor()
SYNOPSIS:
XmacII produced garbage results from XLookupColor and XAllocNamedColor
calls. Erroneous results were returned and non-existent color names
were not detected. All due to a an unexpected indirection in the
result returned from A/UX 2.0 beta 15 version of the fetch() dbm routine.
DESCRIPTION:
As above for symptoms. The problem was that under this version of A/UX
the documentation, and implementation, of the dbm routines differ
from almost everybody else's. The normal (non-NDBM) version has fetch
defined as:
datum fetch(datum key);
but A/UX has it as:
datum *fetch(datum key);
Note that the man page and the implementation agree on the latter
interpretation but the declaration of fetch() in /usr/include/dbm.h
is in the former style!
The subsequent accesses to datum fields produce junk as they are
effectively the contents of whatever happened to be pointed to
by a0 (cc) or whatever is in d0/d1 (gcc). The only other affected
part of the X Window System is the showrgb utility for dumping
the color database.
REPEAT BY:
Run the showrgb utility on your rgb database. It uses fetch() and
hence prints out rubbish results (normally many lines of:
"0 0 0 <lots of nulls or other junk instead of a color name>"
).
SAMPLE FIX:
First fix /usr/include/dbm,h:
44c44,45
< datum fetch();
---
> datum *fetch(); /* was datum rather than datum *, but is datum * in docs!
> kieron - UniSoft Ltd, 9th October 1990 */
The following diffs will fix mit/server/os/4.2bsd/ocolor.c:
74,75d78
> #ifdef macII
> /* A/UX has a brain damaged view of fetch as datum *fetch(), kieron */
> dbent = *fetch (dbent);
> #else
75a80
> #endif macII
and the following will deal with mit/rgb/showrgb.c:
32,32c37
< #define dbm_fetch(db,key) (fetch(key))
---
> /* A/UX has fetch returning a datum * rather than a datum !!! - kieron */
> #ifdef macII
> # define dbm_fetch(db,key) (*fetch(key))
> #else
> # define dbm_fetch(db,key) (fetch(key))
> #endif macII
--
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)x@springer.Apple.COM (X Windows) (10/12/90)
In article <2463@root44.co.uk>, kieron@root.co.uk (Kieron Drake) writes: |> |> DESCRIPTION: |> |> As above for symptoms. The problem was that under this version of A/UX |> the documentation, and implementation, of the dbm routines differ |> from almost everybody else's. The normal (non-NDBM) version has fetch |> defined as: |> datum fetch(datum key); |> but A/UX has it as: |> datum *fetch(datum key); |> |> Note that the man page and the implementation agree on the latter |> interpretation but the declaration of fetch() in /usr/include/dbm.h |> is in the former style! |> 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 -- springer.x 203% rlog rgb.c RCS file: RCS/rgb.c,v; Working file: rgb.c head: 1.2 locks: ; strict access list: x mgchow peters davep symbolic names: v2_1d3: 1.2; GoldenMaster: 1.2; R4UpdateAlpha1: 1.2; comment leader: " * " total revisions: 2; selected revisions: 2 description: Initial Apple Check In. ---------------------------- revision 1.2 date: 90/01/08 21:43:17; author: x; state: Exp; lines added/del: 3/3 pcc blows code generation for e.g. rgb.red = (red * 65535)/255, emitting a divs.w. Forced assignement to a long to fix it. SCP. ---------------------------- revision 1.1 date: 90/01/08 21:30:16; author: x; state: Exp; Initial revision ======================================================================== ====== springer.x 204% rcsdiff -c -r1.1 rgb.c RCS file: RCS/rgb.c,v retrieving revision 1.1 diff -c -r1.1 rgb.c *** /tmp/,RCSt1a03577 Thu Oct 11 15:09:46 1990 --- rgb.c Tue May 29 14:10:15 1990 *************** *** 118,126 **** name[i] = tolower (name[i]); } key.dsize = n; ! rgb.red = (red * 65535) / 255; ! rgb.green = (green * 65535) / 255; ! rgb.blue = (blue * 65535) / 255; if (dbm_store (rgb_dbm, key, content, DBM_REPLACE)) { fprintf (stderr, "%s: store of entry \"%s\" failed\n", ProgramName, name); --- 118,126 ---- name[i] = tolower (name[i]); } key.dsize = n; ! rgb.red = red = (red * 65535) / 255; ! rgb.green = green = (green * 65535) / 255; ! rgb.blue = blue = (blue * 65535) / 255; if (dbm_store (rgb_dbm, key, content, DBM_REPLACE)) { fprintf (stderr, "%s: store of entry \"%s\" failed\n", ProgramName, name); Steve Peters X Project Leader Apple Computer, Inc. peters@apple.apple.com
kieron@root.co.uk (Kieron Drake) (10/15/90)
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)