Le primidi 11 nivôse, an CCXIII, Branden Robinson a écrit :
> I'm pretty nervous about changing a public Xlib data structure like this.
> Can someone patiently explain to me why there's no way this could possibly
> be construed as an ABI change?
I would almost sayt it is the opposite of an ABI change. The exact
description of this problem is that the Xlib header fails to describe
properly the ABI of the Xlib. More precisely, it make assumptions about the
memory layout of structures that are left implementation-defined by the C
standard, and are not met by gcc on the ARM processor with the default
options.
Let me enter into details: the XDrawString16 allows to draw strings using an
enlarget character set. According to the name, we expect that each character
will be coded using 2 octets. The Xlib.h header defines the data structure
used to code one character:
typedef struct { /* normal 16 bit characters are two bytes */
unsigned char byte1;
unsigned char byte2;
} XChar2b;
Now, the C standard does not tell us this structure makes 2 octets. Indeed,
on ARM with gcc default options, sizeof(XChar2b) is 4: to octets for byte1
and byte2, and to padding octets.
The problem is that, as far as I can see, the Xlib expect only 2 octets per
character. I was too lazy to read and understand the full source code for
this function, but I suspect it just makes a memory copy of the string in
the send-buffer for the X-server¹. It is obvious if one tries to pass a
hand-made char array to the XDrawString16.
There are two possible bug-fix for this:
- correct the XDrawString16 (and similar) function so that it uses the
correct 4-octets XChar2b structure layout;
- correct the applications so that they use a 2-octets XChar2b structure.
The first one is changing the current ABI of the Xlib to make it compatible
with its header. The second one requires either a gcc attribute to the
structure or a build option.
Note that there are no standard (gcc-independant) way to do the second one.
Nonetheless, I think it is the best solution.
----
1: There is something to check here: XDrawString16 takes a length argument,
does it use length*2 or length*sizeof(XChar2b) octets from the string
buffer? If it uses length*sizeof(XChar2b), there will be garbage in the
send buffer, and one would expect the X-server to signal a Bad Request
pretty soon. Since xterm works with the corrected XChar2b structure, I
suppose it is length*2, so the Xlib is internally coherent.
Attachment:
pgpD69gZNFNc2.pgp
Description: PGP signature