From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Making --with-wide-int the default Date: Tue, 17 Nov 2015 13:13:06 +0100 Message-ID: <87a8qcj031.fsf@fencepost.gnu.org> References: <83oag087gs.fsf@gnu.org> <83oafz70im.fsf@gnu.org> <5620AF43.4050401@cs.ucla.edu> <83k2qn6xfm.fsf@gnu.org> <5620B4FA.1000804@cs.ucla.edu> <83wptojs1r.fsf@gnu.org> <56444C66.8050506@gmx.at> <83r3jugx8g.fsf@gnu.org> <87io56nu0a.fsf@fencepost.gnu.org> <83lha1dl87.fsf@gnu.org> <871tbrmeu3.fsf@fencepost.gnu.org> <564A63FB.7040209@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447762399 11487 80.91.229.3 (17 Nov 2015 12:13:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 12:13:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 13:13:19 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zyf8Q-0000JZ-Re for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 13:13:19 +0100 Original-Received: from localhost ([::1]:57816 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyf8Q-00078a-HP for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 07:13:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyf8M-000786-CL for emacs-devel@gnu.org; Tue, 17 Nov 2015 07:13:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zyf8I-0000AO-2a for emacs-devel@gnu.org; Tue, 17 Nov 2015 07:13:14 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyf8F-00009v-Ch; Tue, 17 Nov 2015 07:13:07 -0500 Original-Received: from localhost ([127.0.0.1]:47203 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1Zyf8E-0004WS-Hl; Tue, 17 Nov 2015 07:13:06 -0500 Original-Received: by lola (Postfix, from userid 1000) id 3CA22DF5D2; Tue, 17 Nov 2015 13:13:06 +0100 (CET) In-Reply-To: <564A63FB.7040209@cs.ucla.edu> (Paul Eggert's message of "Mon, 16 Nov 2015 15:17:15 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:194638 Archived-At: Paul Eggert writes: > On 11/15/2015 08:01 AM, David Kastrup wrote: >> I can tell, and >> >> git grep XINT >> >> shows lots of assignments to variables of type int rather than >> EMACS_INT. I think that there should be macros XINT, XUINT, XEINT (for >> EMACS_INT) which trigger a range error when the value does not fit the >> respective range. Possibly also XLONG and XULONG but I'm not sure we >> actually have platforms where long/int are different. > > There's no need XEINT etc., as this work has already been done, using > macros like CHECK_TYPE_RANGED_INTEGER to make sure that XINT returns > values in range for a C integer type. This has to be called explicitly. There are several consequences of the current choices: for one thing, one cannot enable C compiler warnings about too small integer types since any assignment of XINT to an int will trigger such a warning, making them useless for detecting actual problems. As one consequence, every single use of XINT needs manual code review. As another consequence, we'll have to redo all of the code review when moving to Guile and/or arbitrary precision integers since the current code obviously assumes that EMACS_INT is large enough for any integer value representable in Lisp. Guile has all of -- C Function: char scm_to_char (SCM x) -- C Function: signed char scm_to_schar (SCM x) -- C Function: unsigned char scm_to_uchar (SCM x) -- C Function: short scm_to_short (SCM x) -- C Function: unsigned short scm_to_ushort (SCM x) -- C Function: int scm_to_int (SCM x) -- C Function: unsigned int scm_to_uint (SCM x) -- C Function: long scm_to_long (SCM x) -- C Function: unsigned long scm_to_ulong (SCM x) -- C Function: long long scm_to_long_long (SCM x) -- C Function: unsigned long long scm_to_ulong_long (SCM x) -- C Function: size_t scm_to_size_t (SCM x) -- C Function: ssize_t scm_to_ssize_t (SCM x) -- C Function: scm_t_ptrdiff scm_to_ptrdiff_t (SCM x) -- C Function: scm_t_int8 scm_to_int8 (SCM x) -- C Function: scm_t_uint8 scm_to_uint8 (SCM x) -- C Function: scm_t_int16 scm_to_int16 (SCM x) -- C Function: scm_t_uint16 scm_to_uint16 (SCM x) -- C Function: scm_t_int32 scm_to_int32 (SCM x) -- C Function: scm_t_uint32 scm_to_uint32 (SCM x) -- C Function: scm_t_int64 scm_to_int64 (SCM x) -- C Function: scm_t_uint64 scm_to_uint64 (SCM x) -- C Function: scm_t_intmax scm_to_intmax (SCM x) -- C Function: scm_t_uintmax scm_to_uintmax (SCM x) When X represents an exact integer that fits into the indicated C type, return that integer. Else signal an error, either a =E2=80=98wrong-type=E2=80=99 error when X is not an exact integer, or = an =E2=80=98out-of-range=E2=80=99 error when it doesn=E2=80=99t fit the g= iven range. The functions =E2=80=98scm_to_long_long=E2=80=99, =E2=80=98scm_to_ulon= g_long=E2=80=99, =E2=80=98scm_to_int64=E2=80=99, and =E2=80=98scm_to_uint64=E2=80=99 ar= e only available when the corresponding types are. What does that mean? For one thing it means that the C compiler can have all of its warnings for losing significant bits enabled meaningfully. For another it means that converting a Lisp integer to something used is a C routine will either succeed or throw an error. The reverse conversions all succeed, and naturally without ever losing any precision (as opposed to our current conversion which, I think, silently drops a few bits from the top of any EMACS_INT when converting to Lisp_Object . Integer overflows are a rather popular source of security vulnerabilities and/or crashes, so having them under control by default is a good idea and means that we don't need to start rereviewing everything whenever our integer representation changes. --=20 David Kastrup