From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id DDD4B1F461 for ; Sat, 29 Jun 2019 17:31:41 +0000 (UTC) Received: from localhost ([::1]:41618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhHCN-0001FM-SK for normalperson@yhbt.net; Sat, 29 Jun 2019 13:31:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33992) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhHCL-0001FE-3P for bug-gnulib@gnu.org; Sat, 29 Jun 2019 13:31:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhHCK-00039o-1B for bug-gnulib@gnu.org; Sat, 29 Jun 2019 13:31:37 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44514) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hhHCJ-00038m-RT for bug-gnulib@gnu.org; Sat, 29 Jun 2019 13:31:35 -0400 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) 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) 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 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) 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) Subject: Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers To: Pip Cet References: <2715311.ceefYqj39C@omega> <8979488.cRkkfcT1mV@omega> <87168b28-192b-6666-e9b6-9cdc2ed3917a@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <791ae316-3a6f-605a-0da5-874fe3d224c5@cs.ucla.edu> Date: Sat, 29 Jun 2019 10:31:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 36370@debbugs.gnu.org, bug-gnulib@gnu.org, Bruno Haible Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" 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.