From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs-diffs Digest, Vol 94, Issue 89 Date: Fri, 24 Sep 2010 22:19:10 +0200 Message-ID: <83r5gisxmp.fsf@gnu.org> References: <83zkv7rmpe.fsf@gnu.org> <83tylesyyk.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1285359597 3181 80.91.229.12 (24 Sep 2010 20:19:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 24 Sep 2010 20:19:57 +0000 (UTC) To: larsi@gnus.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 24 22:19:55 2010 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.69) (envelope-from ) id 1OzEkN-0002tp-9Z for ged-emacs-devel@m.gmane.org; Fri, 24 Sep 2010 22:19:55 +0200 Original-Received: from localhost ([127.0.0.1]:39448 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzEkM-0006RX-J3 for ged-emacs-devel@m.gmane.org; Fri, 24 Sep 2010 16:19:54 -0400 Original-Received: from [140.186.70.92] (port=45616 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OzEkC-0006QO-BP for emacs-devel@gnu.org; Fri, 24 Sep 2010 16:19:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OzEk7-0001sL-J3 for emacs-devel@gnu.org; Fri, 24 Sep 2010 16:19:44 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:53268) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OzEk7-0001sB-8i for emacs-devel@gnu.org; Fri, 24 Sep 2010 16:19:39 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L9900M00PNPOA00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 24 Sep 2010 22:19:04 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.203.3]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L9900MHHPRRLH20@a-mtaout20.012.net.il>; Fri, 24 Sep 2010 22:19:04 +0200 (IST) In-reply-to: <83tylesyyk.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:130804 Archived-At: > Date: Fri, 24 Sep 2010 21:50:27 +0200 > From: Eli Zaretskii > Cc: emacs-devel@gnu.org > > > From: Lars Magne Ingebrigtsen > > Date: Fri, 24 Sep 2010 21:41:24 +0200 > > > > Eli Zaretskii writes: > > > > > Is this really a good idea? There's no chance the number of lines in > > > a frame will overflow a 32-bit int any time soon. SO I think an > > > explicit cast to int is a better solution here. > > > > That was my first impulse, too, but the other int casting got negative feedback.. > > You mean, GCC still complains? Or maybe you mean that Stefan thought casting was not the best idea. In that case, I'd like Stefan's opinion on this one: > - int frame_lines = FRAME_LINES (frame); > + EMACS_INT frame_lines = FRAME_LINES (frame); I think down that lane lies madness, because we have lots of struct members that are Lisp integers, and assigning the result of XINT of every one of them to an EMACS_INT will significantly and unnecessarily increase our stack usage (on 64-bit machines).