lcs@icad.COM (Larry Stone) (02/07/91)
Does the definition of the X protocol officially guarantee that 16-bit
values will be aligned on 16-bit boundaries (and likewise for 32-bit
values)? The encoding of the PolyText16 request appears to be capable
of misaligning 16-bit values.
The problem occurs when encoding a request that includes font changes:
The fixed part of the request occupies an even number of bytes. The
LISTofTEXTITEM16 can include text elements (1 byte length, 1 byte delta,
list of CHAR2B's for a total that is sure to be an even number), and
font changes, which are five (5) bytes long. It seems reasonable to
expect that font changes and text strings will be interleaved, as in:
Req: <fixed part of request> <some text> <font change> <more text>
Byte: 0 16 20 25
The first text item after the first font change is inevitably
misaligned. I haven't tried it with Xlib, but the sample CLX library
from MIT X11R4 (the latest version on expo) breaks when trying to encode
a request like the one shown above because an optimized copy routine
tries to write misaligned data.
After hacking the library to work anyway, I discovered that the MIT sample
server and Sun X11/NeWS accept these requests and excute them correctly.
(Servers used were MIT X11R4 (pl 14) on DECstation, and SunOS 4.1).
XScope isn't much help, though, it appears to get confused by font changes.
Is my interpretation of the protocol spec accurate? The O'Reilly
edition claims, on p. 8, that "16 and 32-bit values within the messages
are always placed on 16 and 32-bit boundaries". I could not find any
statement about alignment in the MIT document, though. There is an
inherent contradiction here, unless PolyText16 requests should always
encode font changes in pairs :-). Are there any other requests that can
cause misaligned data to be encoded?
thanks,
-- Larry lcs@icad.comrws@expo.lcs.mit.EDU (Bob Scheifler) (02/07/91)
Does the definition of the X protocol officially guarantee that 16-bit
values will be aligned on 16-bit boundaries (and likewise for 32-bit
values)?
The encoding makes it happen in most, but not all, cases.
The encoding of the PolyText16 request appears to be capable
of misaligning 16-bit values.
No, it misaligns 32-bit values (the font ids). CHAR2B are specified as
2 bytes, not as 16-bit integers, so they aren't misaligned. :-)