Mike FABIAN writes: Thanks for the patch! (1) As I understand it the crash is presumably caused by a buffer overrun overwriting the stack, not in the codec trying to decode a corrupt (truncated) selection string, right? Ie, the problem leading to a crash has been fixed here, it's not something in the codec that is masked by giving it uncorrupt data? (2) Now, this looks like a bug in the 64-bit X libraries to me. What happens if it gets fixed? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen J. Turnbull wrote: It isn't a bug, it's a design decision (a bad one, IMHO). IOW, it isn't going to get "fixed". The latest version of the XGetWindowProperty() manpage is more explicit: If the returned format is 8, the returned data is represented as a char array. If the returned format is 16, the returned data is represented as a short array and should be cast to that type to obtain the ele- ments. If the returned format is 32, the returned data is represented as a long array and should be cast to that type to obtain the elements. The sizes used by XGetWindowProperty() (e.g. bytes_after_return) refer to the sizes in terms of the X protocol (e.g. 4 bytes for CARD32), which isn't necessarily the same as used in the client. Similar issues apply to properties whose values are structures (e.g. XSizeHints). The actual property will be defined in terms of CARD32s, but the corresponding Xlib structure will typically contain a mix of "int"s and "long"s. This sort of issue is the main reason why the 64-bit Windows ABI has a 32-bit "long"; there are just too many cases where structures containing "long" fields get written directly (fwrite() etc) to files or sockets. -- Glynn Clements <glynn(a)gclements.plus.com&gt; _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta