From owner-freebsd-ports-bugs@FreeBSD.ORG Fri Jan 4 15:25:22 2008 Return-Path: Delivered-To: freebsd-ports-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5D9616A418; Fri, 4 Jan 2008 15:25:22 +0000 (UTC) (envelope-from kasahara@nc.kyushu-u.ac.jp) Received: from elvenbow.cc.kyushu-u.ac.jp (unknown [IPv6:2001:200:905:1314::80]) by mx1.freebsd.org (Postfix) with ESMTP id D0CC413C46E; Fri, 4 Jan 2008 15:25:21 +0000 (UTC) (envelope-from kasahara@nc.kyushu-u.ac.jp) Received: from localhost (kasahara@localhost [IPv6:::1]) by elvenbow.cc.kyushu-u.ac.jp (8.14.1/8.14.1) with ESMTP id m04FP6eB005161; Sat, 5 Jan 2008 00:25:11 +0900 (JST) (envelope-from kasahara@nc.kyushu-u.ac.jp) Date: Sat, 05 Jan 2008 00:25:06 +0900 (JST) Message-Id: <20080105.002506.772669040454084046.kasahara@nc.kyushu-u.ac.jp> To: pav@FreeBSD.org From: Yoshiaki Kasahara In-Reply-To: <1199454928.1192.32.camel@pav.hide.vol.cz> References: <200801041336.m04Davse003158@freefall.freebsd.org> <20080104.224625.723503462517847649.kasahara@nc.kyushu-u.ac.jp> <1199454928.1192.32.camel@pav.hide.vol.cz> X-Fingerprint: CDA2 B6B6 6796 0DD3 9D80 2602 E909 4623 A15E A074 X-URL: http://www.nc.kyushu-u.ac.jp/~kasahara/ X-Mailer: Mew version 5.2.53 on Emacs 23.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/98590: [FIX] ports rxvt-devel on amd64 crashes inside rxvt_selection_send() X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 15:25:22 -0000 On Fri, 04 Jan 2008 14:55:28 +0100, Pav Lucistnik said: > Can you verify this does the right thing on both i386 and amd64? How can I verify that? (How can I satisfy the requirement?) Actually I'm not confident about my patch. I tried to build rxvt-devel on an i386 platform with the patch. It seems that it didn't change the behavior of cut & paste. And at least I'm sure it doesn't change anything on i386 (because the values before and after the patch are equivalent), and it prevents crash on amd64. The 5th argument of XChangeProperty is 'int format', and it only accepts 8, 16, and 32. from the manpage of XChangeProperty(3): format Specifies whether the data should be viewed as a list of 8-bit, 16-bit, or 32-bit quantities. Possible values are 8, 16, and 32. This information allows the X server to cor- rectly perform byte-swap operations as necessary. If the format is 16-bit or 32-bit, you must explicitly cast your data pointer to an (unsigned char *) in the call to XChange- Property. 'Time' is defined in /usr/local/include/X11/X.h as typedef unsigned long Time; On i386, sizeof(Time) is 4, so 8*4=32 is a valid input for XChangeProperty. On amd64, sizeof(Time) is 8, so 8*8=64 is an invalid input for that (triggers XError). To tell the truth, I don't know how to pass a 64bit parameter to XChangeProperty (r->h->selection_time is 64bit on amd64). So, using '32' doesn't change the behaviour on i386, but I'm not really sure on amd64. Maybe only lower 4 bytes are used (guessed only from the following description of the manpage) prop_return Returns the data in the specified format. 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 array of short int type and should be cast to that type to obtain the elements. If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes). Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasahara@nc.kyushu-u.ac.jp