From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Making 'eq' == 'eql' in bignum branch Date: Wed, 22 Aug 2018 06:55:30 -0700 Organization: UCLA Computer Science Department Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <877em1cb0i.fsf@tromey.com> <765767b2-d2e5-a9a6-f724-d58ecf4847bb@cs.ucla.edu> <76081b5d-8c10-0a37-2c97-d4864c0faa80@cs.ucla.edu> <09153aed-361d-4f82-d9ac-b502314769ae@cs.ucla.edu> <83k1oldqao.fsf@gnu.org> <87r2irvk5f.fsf@gmail.com> <87k1ojv8oa.fsf@gmail.com> <62ffbb4d-97e8-1359-5b73-b6add8cc3d1c@cs.ucla.edu> <5344e795b8e6402998dd78df493862de@lanl.gov> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1534946057 30775 195.159.176.226 (22 Aug 2018 13:54:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 22 Aug 2018 13:54:17 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: "emacs-devel@gnu.org" To: "Herring, Davis" , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 22 15:54:12 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsTaO-0007sx-HA for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2018 15:54:12 +0200 Original-Received: from localhost ([::1]:59207 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsTcU-0006EU-L7 for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2018 09:56:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsTbq-0006D5-O3 for emacs-devel@gnu.org; Wed, 22 Aug 2018 09:55:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsTbl-0003Cg-3C for emacs-devel@gnu.org; Wed, 22 Aug 2018 09:55:42 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54864) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fsTbh-00039y-4C for emacs-devel@gnu.org; Wed, 22 Aug 2018 09:55:35 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BC1E11605BB; Wed, 22 Aug 2018 06:55:31 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id nk1ICOzcP5od; Wed, 22 Aug 2018 06:55:31 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0F8D9160656; Wed, 22 Aug 2018 06:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uyDPGmY3yHWm; Wed, 22 Aug 2018 06:55:30 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id B209E1605BB; Wed, 22 Aug 2018 06:55:30 -0700 (PDT) In-Reply-To: <5344e795b8e6402998dd78df493862de@lanl.gov> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:228809 Archived-At: Herring, Davis wrote: > this is far from the only place in Emacs where what is formally undefined behavior is expected to "do the obvious thing" Emacs does not rely on undefined behavior for integer arithmetic. Even in Emacs 26, (abs most-negative-fixnum) yields most-negative-fixnum without doing anything undefined at the C level, because (- most-negative-fixnum) fits within machine limits and the tagging operation does not overflow. Although there may be a few places left in Emacs that rely on undefined integer behavior, these are now considered bugs and occasionally I try to stamp them out by building with gcc -fsanitize=undefined. For example, in Emacs 26 (* most-positive-fixnum most-positive-fixnum) returns 1 (the overflowed value) without overflowing at the C level. Emacs *does* rely on undefined behavior when it tags pointers, but that's a different kettle of fish.