[nicolas.george at ens.fr: Re: Bug#285396: [ARM] wide chars don't work]

[Carl Worth]

I'm sending this message on behalf of Branden Robinson, (who is having
trouble getting messages to this list for some reason).

-Carl

From: Branden Robinson <branden at debian.org>
Subject: [nicolas.george at ens.fr: Re: Bug#285396: [ARM] wide chars don't work]
To: xorg at lists.freedesktop.org, control at bugs.debian.org
Resent-Date: Tue, 11 Jan 2005 11:23:26 -0500
Date: Tue, 11 Jan 2005 06:21:18 -0500

forwarded 285396 xorg at 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 at ens.fr> -----

From: Nicolas George <nicolas.george at ens.fr>
To: Branden Robinson <branden at debian.org>, 285396 at bugs.debian.org
Cc: 285396-submitter at bugs.debian.org, debian-arm at lists.debian.org,
	Gaetan Leurent <gaetan.leurent at 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 at 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 at debian.org                 |    a sense of humor to console him for
http://people.debian.org/~branden/ |    what he is.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050111/7893d76d/attachment.pgp>