From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#36370: 27.0.50; XFIXNAT called on negative numbers Date: Sat, 29 Jun 2019 10:31:30 -0700 Organization: UCLA Computer Science Department Message-ID: <791ae316-3a6f-605a-0da5-874fe3d224c5__35522.6398025238$1561829539$gmane$org@cs.ucla.edu> References: <2715311.ceefYqj39C@omega> <8979488.cRkkfcT1mV@omega> <87168b28-192b-6666-e9b6-9cdc2ed3917a@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="249609"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 Cc: 36370@debbugs.gnu.org, Bruno Haible , bug-gnulib@gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 29 19:32:10 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hhHCr-0012lh-U6 for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Jun 2019 19:32:10 +0200 Original-Received: from localhost ([::1]:41622 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhHCq-0001OX-Sp for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Jun 2019 13:32:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34088) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhHCl-0001OE-Kj for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2019 13:32:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhHCk-0003VH-IG for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2019 13:32:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59563) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hhHCk-0003V6-E0 for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2019 13:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hhHCk-0005Ht-9j for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2019 13:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Jun 2019 17:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36370 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 36370-submit@debbugs.gnu.org id=B36370.156182950520301 (code B ref 36370); Sat, 29 Jun 2019 17:32:02 +0000 Original-Received: (at 36370) by debbugs.gnu.org; 29 Jun 2019 17:31:45 +0000 Original-Received: from localhost ([127.0.0.1]:44874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hhHCQ-0005HK-LJ for submit@debbugs.gnu.org; Sat, 29 Jun 2019 13:31:44 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hhHCN-0005Gn-2c for 36370@debbugs.gnu.org; Sat, 29 Jun 2019 13:31:40 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 91C66161D51; Sat, 29 Jun 2019 10:31:32 -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 GLMV5O1SKavM; Sat, 29 Jun 2019 10:31:31 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9455E161D92; Sat, 29 Jun 2019 10:31: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 lL41p-qcONmX; Sat, 29 Jun 2019 10:31:31 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3C544161D51; Sat, 29 Jun 2019 10:31:31 -0700 (PDT) In-Reply-To: Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:161836 Archived-At: Pip Cet wrote: >> This is not a valid use of 'assume'. It's documented that assume's argument >> should be free of side effects. > > But the compiler makes no such assumption Sure, but if the caller uses 'assume' contrary to its documentation, that's a problem with the caller's code, not with 'assume'. It's merely an implementation detail as to which pothole the problematic code runs into. > if GCC decided to add a > __builtin_assume() builtin, we could give it slightly different > semantics: that the expression passed to it evaluates to true, but > doesn't evaluate to false or fail to evaluate. Something like > __attribute__((does_return)) might do on a function. Yes, the expression should return true without side effects or looping. I don't see this as an significant difference in semantics. One should also not call Gnulib assume (R) with an expression that loops forever, as this defeats the intent of 'assume' which is to make code more efficient. If there's any real confusion about this issue, we can add it to the 'assume' documentation as well. > Also, "should" doesn't mean "must", does it? It's not the "should" of an Internet RFC. It's more the "should" of "you should do this, and if you don't you're on your own". > I'd prefer rewording that > sentence as "R may or may not be evaluated: it should not normally > have side-effects". Better to say that it should not have side effects at all. There's no "normally" about that. Side effects are trouble. > wouldn't it be even > nicer to give up (most of) the distinction between assert and assume > and just tell people to use assume? No, because 'assert (false)' has well-defined behavior, whereas behavior is undefined for programs that do 'assume (false)' . This is a fundamental difference between the two.