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: size_t vs EMACS_INT Date: Sat, 16 Jul 2011 10:13:05 +0300 Message-ID: <83pqlahf5q.fsf@gnu.org> References: <8362n4hwny.fsf@gnu.org> <4E1FE8F8.4050501@cs.ucla.edu> <834o2ohsku.fsf@gnu.org> <4E206D05.3030100@cs.ucla.edu> <83r55rh3ew.fsf@gnu.org> <4E20B6B8.6030606@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1310800290 27449 80.91.229.12 (16 Jul 2011 07:11:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 16 Jul 2011 07:11:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 16 09:11:25 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qhz24-00019Y-Un for ged-emacs-devel@m.gmane.org; Sat, 16 Jul 2011 09:11:25 +0200 Original-Received: from localhost ([::1]:50583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qhz22-0001iQ-Vi for ged-emacs-devel@m.gmane.org; Sat, 16 Jul 2011 03:11:23 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qhz1p-0001iI-5y for emacs-devel@gnu.org; Sat, 16 Jul 2011 03:11:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qhz1n-0006ZU-So for emacs-devel@gnu.org; Sat, 16 Jul 2011 03:11:09 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:45028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qhz1n-0006ZO-JH for emacs-devel@gnu.org; Sat, 16 Jul 2011 03:11:07 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LOE00000ZXSI800@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 16 Jul 2011 10:10:57 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.133.66]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LOE00M4XZY8W0H0@a-mtaout22.012.net.il>; Sat, 16 Jul 2011 10:10:57 +0300 (IDT) In-reply-to: <4E20B6B8.6030606@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142041 Archived-At: > Date: Fri, 15 Jul 2011 14:52:56 -0700 > From: Paul Eggert > CC: emacs-devel@gnu.org > > EMACS_INT new_point = PT + XINT (n); > > This code is currently safe, since C code can always safely add > two Emacs fixnums, and the addition can't possibly overflow at the C level. > But if fixnums could equal TYPE_MAXIMUM (EMACS_INT), > this code would be unsafe and we would have to add a run-time > check for integer overflow. But this issue exists with any addition of two integer values of the same type in a C program. And yet gobs of C programs do that without testing for overflow before each addition. Why should Emacs be different? Also, the fact that the underlying C data type cannot overflow doesn't save us from disasters, because calling make_number on the result could still "kind of" overflow, when it bit-shifts the value.