forwarded 285396 xorg@lists.freedesktop.org thanks M. George, below, appears to make a pretty strong case for changing an Xlib header. --- /usr/X11R6/include/X11/Xlib.h 2004-09-30 16:54:31.000000000 +0200 +++ X11/Xlib.h 2004-12-13 02:54:16.000000000 +0100 @@ -1059,7 +1059,11 @@ typedef struct { /* normal 16 bit characters are two bytes */ unsigned char byte1; unsigned char byte2; -} XChar2b; +} +#ifdef __GNUC__ +__attribute__ ((packed)) +#endif +XChar2b; typedef struct { XChar2b *chars; /* two byte characters */ I can't think of any objections, but I do not consider myself strongly conversant with alignment/portability issues. But I don't trust myself enough to judge this issue, and it would be hideously disruptive for me to commit a change of this nature to Debian's libx11-dev package even to Debian unstable. Would anyone here like to comment? "Stop worrying and do it, Branden," is as much as I need to hear, if you're someone I trust. :) ----- Forwarded message from Nicolas George <nicolas.george@ens.fr> ----- From: Nicolas George <nicolas.george@ens.fr> To: Branden Robinson <branden@debian.org>, 285396@bugs.debian.org Cc: 285396-submitter@bugs.debian.org, debian-arm@lists.debian.org, Gaetan Leurent <gaetan.leurent@ens.fr> Subject: Re: Bug#285396: [ARM] wide chars don't work Date: Mon, 3 Jan 2005 00:38:12 +0100 Message-ID: <[🔎] 20050102233812.GA9962@clipper.ens.fr> User-Agent: Mutt/1.4.2i X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.0.2 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. ----- End forwarded message ----- -- G. Branden Robinson | Imagination was given man to Debian GNU/Linux | compensate for what he is not, and branden@debian.org | a sense of humor to console him for http://people.debian.org/~branden/ | what he is.
Attachment:
signature.asc
Description: Digital signature