handeli@anduin.llnl.gov (09/07/90)
Installation of Xlib on NLTSS on CRAY XMP and YMP systems has been
made difficult due to the fact that the LLNL C compiler (not related
to any UNICOS
CRI-supported C compilers) does not pack bytes inside structures.
Thus, in
a typical structure such as
struct{
char a;
char b;
char c[30];
} tt;
The LLNL C compiler would put each of the three variables in
separate 64-bit words. (Note that the c[30] is packed 8 bytes
per word). If one uses the instead the structure
struct {
int a:8;
int b:8;
char c[30];
};
variables a and b will be packed in one word, but then c will be
on a new word boundary.
Specifically, there are five structures in Xproto.h that we have identified
where this problem occurs. They are xSendEventReq, xGetKeyboardControl-
Reply, xEvent, xChangePropertyReq, and xKeymapEvent. There is a 6th
structure with the above form, but just by chance, the array part of the structure
starts on a word boundary with no empty spaces. The question is then what
modifications are needed to Xlib to compensate for this problem. I have
determined at least two areas. First, there are most definitely places
where these structures need to be packed and unpacked. We need to know
exactly and precisely where this needs to be done. The many calls to lower
level data communications routine complicates the determination of these
locations. Secondly, Xlib has the SIZEOF macro which has hardwired in the
length in bytes of these structures. SIZEOF does appear in BCOPY calls as
well as several other cases, scattered about the Xlib sources. The question
is then what effect will having a structure with the wrong size with spaces
in it have on Xlib? Finally, are there any other things I haven't discovered
yet concerning non-packed structures?