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.com
rws@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. :-)