From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: LGLYPH_SET_CODE Date: Fri, 29 Aug 2008 20:17:50 +0900 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1220008766 30546 80.91.229.12 (29 Aug 2008 11:19:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Aug 2008 11:19:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 29 13:20:19 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KZ21a-00008f-NJ for ged-emacs-devel@m.gmane.org; Fri, 29 Aug 2008 13:20:18 +0200 Original-Received: from localhost ([127.0.0.1]:36659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZ20b-0007b4-P3 for ged-emacs-devel@m.gmane.org; Fri, 29 Aug 2008 07:19:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZ1zV-0006aZ-Jd for emacs-devel@gnu.org; Fri, 29 Aug 2008 07:18:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZ1zS-0006WN-9Q for emacs-devel@gnu.org; Fri, 29 Aug 2008 07:18:08 -0400 Original-Received: from [199.232.76.173] (port=43670 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZ1zR-0006Vn-BP for emacs-devel@gnu.org; Fri, 29 Aug 2008 07:18:05 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:59441) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZ1zH-0007Kx-Cj; Fri, 29 Aug 2008 07:17:55 -0400 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id m7TBHp36017422; Fri, 29 Aug 2008 20:17:51 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id m7TBHphk014417; Fri, 29 Aug 2008 20:17:51 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp1.aist.go.jp with ESMTP id m7TBHoTe023239; Fri, 29 Aug 2008 20:17:50 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken.m17n.org with local (Exim 4.69) (envelope-from ) id 1KZ1zC-0005Dc-Kz; Fri, 29 Aug 2008 20:17:50 +0900 In-reply-to: (message from Eli Zaretskii on Fri, 29 Aug 2008 11:44:58 +0300) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-detected-kernel: by monty-python.gnu.org: Solaris 9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103163 In article , Eli Zaretskii writes: > Can the second argument to this macro be negative? If so, > the current definition: > #define LGLYPH_SET_CODE(g, val) \ > do { \ > if (val == FONT_INVALID_CODE) \ > ASET ((g), LGLYPH_IX_CODE, Qnil); \ > else if ((EMACS_INT)val > MOST_POSITIVE_FIXNUM) \ > ASET ((g), LGLYPH_IX_CODE, Fcons (make_number ((val) >> 16), \ > make_number ((val) & 0xFFFF)));\ > else \ > ASET ((g), LGLYPH_IX_CODE, make_number (val)); \ > } while (0) > does not handle such values correctly, because their > absolute value could be large enough to overflow an > EMACS_INT. If negative values are possible, we should use > FIXNUM_OVERFLOW_P instead of a comparison with > MOST_POSITIVE_FIXNUM. It is intended that VAL is not negative. That macro is called at four places, and except for one place, it is assured that VAL is never negative. The exception is in uniscribe_shape of w32uniscribe.c: LGLYPH_SET_CODE (lglyph, glyphs[j]); The type of glyphs[j] is "WORD" and I don't know if it's unsigned or not, I don't know if ScriptShape set a negative value in it or not. Anyway, if it's possible that glyphs[j] becomes negative, that function should be modified not to call LGLYPH_SET_CODE with negative VAL. --- Kenichi Handa handa@ni.aist.go.jp