220 35693 article Path: news.gmane.org!.POSTED!not-for-mail From: David Brown Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Rotational shift operator Date: Fri, 01 Dec 2017 16:30:35 +0100 Lines: 102 Approved: news@gmane.org Message-ID: References: <69593098-e2cc-487e-bd14-9001b27aa7c1@isocpp.org> <8575602.V2okVmv5xV@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1512142260 10739 195.159.176.226 (1 Dec 2017 15:31:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 15:31:00 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDP6R2XHXIARBK7LQXIQKGQEXPIWBAQ@isocpp.org Fri Dec 01 16:30:51 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f69.google.com ([209.85.215.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKnH3-00022i-Nf for gclcip-std-proposals@m.gmane.org; Fri, 01 Dec 2017 16:30:45 +0100 Original-Received: by mail-lf0-f69.google.com with SMTP id x130sf2593411lff.10 for ; Fri, 01 Dec 2017 07:30:53 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1512142253; cv=pass; d=google.com; s=arc-20160816; b=f34RabQIovUZwa1EjA7ouSUBN+1jZAieZczCXH22r+GrFyxbmWH6mcz8FSwdnSzkbY mF/kkbqUO0dPBRTaRg5wqb9hiHPSkNt+2hESpSU1c7LtvdepqJ6T+7K5zK9NNlw/J/Rk mVgYHaP6grVM/prXDmBUq+sywbunH8u9fSJa8LYfuJqa67YIiPmvvhulOofWi8OE6OMe 9OxDETSd0s26w0N62ZSrRmpCsmzwXbg1+TpVzE4uVBJwQcOO1oKKayWMUfxypuih/GpG VZnI7SOnI+ep2pTdSKGD7dOQTpIdAhJnbNuVDHICjy+Iy2oIal31w35XJTRIxk+MsyKO cBXg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:in-reply-to:user-agent :content-transfer-encoding:mime-version:references:message-id:lines :date:subject:from:to:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=sytmVFBNXjYy4X7U3ULRTjHpls1bDG8i+uiK0kjVi3w=; b=0y3m9iZa5CKNQUKBbSEOk+z/1le8oViOZcgjX4wHWRizYiFEaQJU1S2aL+tHmSTktA ewwYOJtcpm8tnBiOAZfV6A6expI48GTz2kV0mi51SM3jYEC0x0WITr54B+gh1aYPJoHT jrP36Ye32NPHbfIHWr3AgYC4+wJTELn2MZzEk+remDW+7ifBnbKkAZI6vdtFIqtZLVg3 0hg8PAl46c+FMgYNuSKxkD6Xzw/CsoI6gPfwqW9f9T42JnZsMLL53dpxrmiytl0k4q1v cCSUPK7OawW71tiDRuHZUMNuxDhhAhUrgzA326TwxoiDwjoKDmpLKpBoZYU/udWvHyzY ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:date:lines:message-id:references:mime-version :content-transfer-encoding:user-agent:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=sytmVFBNXjYy4X7U3ULRTjHpls1bDG8i+uiK0kjVi3w=; b=2CRswkjM8Hg5RTVNl2A+l56rWnn31y9aiHhUT3Nh8PfWri8Ukspv4isWLpA/46gW4A 5wU/suyIpbr7HYcYgI/8dmcXrt1AtFPeQfPW+MkoWwj22/LTDxvrlWTZrpNFGBTKQEg3 4tsHJC2/axsJ975LZ4V9OOs3ftylBVnc7wE+yzpKmXJofE+5ISiPM9zv4RN6+lqFRmno rmkaUdeDg5O3r2KoBOVxC+mus+42Ax4Y6wif/2ASJhq9gYDgWad3Yl3iEy6tpYDCi6Ik pZ34YQpKQp4W4ml37jpDyZufuKjNqJmMm6+bwwa8pPocMZNFhisePYJjaYEnrLBdTy6g gcCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:content-transfer-encoding:user-agent:in-reply-to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=sytmVFBNXjYy4X7U3ULRTjHpls1bDG8i+uiK0kjVi3w=; b=uUCxk8zjvVP1pgQFDszKQaNfG38F6b2NPKYk9FiPnA5Ngwfs+KN3NwLA43oq+6dTre 4B2c5ObU5x+4eKHo1GdVbU7nZj1fDP6SjyF7d0zSjpMcQ1kJznqjdfHD4ay1udNn1lcI zq3bHGGdLXHNilnVj4yVxxXrmjWwJyqXYND3wz2fG7v6Jl9a58/kzoMxnxn9CugH6MsC eb3/j1YJXbVHwHlyR21wKh3N+6z09TYWeqGA9In5hpOjWi/NrQre0FBKBKDJNKeqe21w /WGpiHUdY4NSPkJ5hRQQmjKKg92PWw/fywaSvWB1kzuxEBRp7AkSONbTERm5wunj X-Gm-Message-State: AJaThX4ZM+K9tn2HoVhogCnBB8EKYUrAkra2XAC/UkA/IKki6goEuKcw p34PXSwNq4V/95TX+bS55C8= X-Google-Smtp-Source: AGs4zMYJkY71lwMhbLvWGcMfG35eE6fGFRk+1SYLec7RWfEo4UdmKlhq7BaU8omGiTMldQeOLw8qlg== X-Received: by 10.46.100.12 with SMTP id y12mr235949ljb.25.1512142253314; Fri, 01 Dec 2017 07:30:53 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.46.82.84 with SMTP id g81ls239409ljb.0.gmail; Fri, 01 Dec 2017 07:30:51 -0800 (PST) X-Received: by 10.25.207.194 with SMTP id f185mr5230423lfg.30.1512142251018; Fri, 01 Dec 2017 07:30:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512142250; cv=none; d=google.com; s=arc-20160816; b=Nbr1Dkm6xT7+tUcOdvxSFUdq6LHyqecjzJAHcZE8lmAhEv5ukrZf6Ti4g/at+oMF6y XPDm02HZ65htKLvXKzq40GpgC3Uee/+vvOIFOqSvCuj2h9GH8ltiJu7+TvtXUceJrvy7 rInobvP6VbRt413K3TQ1RIyEPzFF7hcRbT1pIOsmB6z0oJzILWZZ4aK7QvLuaydQauNY K0JT7RvdmOMwjfWNeRb7xNELuFVvTiyFhAoEZpQjobSLK3HqXyYRdHHhxLIgf57TgX2j jXnXPH0fd9IfYqZyRmv5c1QPTwanTyAbVY8woCxhecskXSVC709Di8KV1QF4y66LeJU0 SxVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:user-agent:content-transfer-encoding:mime-version :references:message-id:lines:date:subject:from:to :arc-authentication-results; bh=jUbT+1D7XZ2wxw7t38ENksEJjDvKhnQPLuhtUCwiyD8=; b=Hi5daMikWFvFJaLrY7ap660igP2UrVPbDlSoEKF0GyRenITq9h7wk4AYKmgrhNp39r /EdDOuRPIpuxHJBI4fd3iBfbs8biDqP7kVuOqckGR9vlZTvfgjpkDDKnGNoQuLP4gTtx lYgsUWtg1v3qZvXkh/qm8dxbNxkiYf5wLMfbvXGsVZfye1KicJSLDyMeYkN1MBpgEUrB RY0VxHp8do0KtCf/3zG0Oo3+EpICLEI6bmR+1M1eTr5Hw+lhivztK6vHsTTU86TmMf+/ IFng5fLKyApDOfrBpniKEeCCye9CakrzvF+eRnGOAik2hL6YohEkpmRQ8N/vrgpEKjz/ xUjA== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org Original-Received: from blaine.gmane.org ([195.159.176.226]) by mx.google.com with ESMTPS id y28si2847190lje.231.2017.12.01.07.30.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 07:30:50 -0800 (PST) Received-SPF: neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) client-ip=195.159.176.226; Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eKnGw-0001jQ-8p for std-proposals@isocpp.org; Fri, 01 Dec 2017 16:30:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 88 Original-X-Complaints-To: usenet@blaine.gmane.org In-Reply-To: X-Original-Sender: david@westcontrol.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 195.159.176.226 is neither permitted nor denied by best guess record for domain of gclcip-std-proposals@m.gmane.org) smtp.mailfrom=gclcip-std-proposals@m.gmane.org Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:35693 Archived-At: On 30/11/17 22:24, Hyman Rosen wrote: > On Thu, Nov 30, 2017 at 3:44 PM, Thiago Macieira > wrote: >=20 > On Thursday, 30 November 2017 11:20:37 PST Hyman Rosen wrote: > > C++ compilers must correctly compile programs even if they are not = portable, > > future-proof, or efficient. >=20 > HOW? >=20 > The very definition of "correctly compile" implies that there's a > specified > and agreed-upon way of doing that. Your code is violating the rules > that the > compiler authors gave you. >=20 >=20 > What do you mean? C++ programs don't have to be portable, and they don't > have to be efficient. Future-proof isn't even a thing, unless you mean > not using > export and auto_ptr when a standard gives them to you. >=20 > The code I posted deliberately had undefined behavior over a subrange of = its > possible inputs. It was correct C++ for the rest of the range, so a C++ > compiler > must compile it to produce the correct behavior for that part of the > range. That > is true even if it turns up its virtual nose at the portability, > efficiency, or > hideboundness of the code. >=20 > The problem, as I see it, is that the compiler arrogates to itself > permission to > delete vast swathes of program if it detects a call to the UB portion of > the range, > even though within the code itself the UB, in the absence of traps, will > have no > effect on the results of the program (assuming non-malicious compilers). >=20 > As usual, Ada got this right decades ago: > >=20 > /Ada 95 introduces the category of bounded errors. Bounded errors > are cases > where the behavior is not deterministic but falls within > well-defined bounds > (Rationale 1995, =C2=A71.4). The consequence of a bounded error is to > limit the > behavior of compilers so that an Ada environment is not free to do > whatever > it wants in the presence of errors. The Ada Reference Manual (1995) > defines > a set of possible outcomes for the consequences of undefined > behavior, as in > an uninitialized value or a value outside the range of its subtype. > For example, > the executing program may raise the predefined exception Program_Erro= r, > Constraint_Error, or it may do nothing./ >=20 C11 has Annex L "Analyzability", which has three types of error: "out of bounds store", "bounded undefined behaviour" and "critical undefined behaviour". Basically, "bounded undefined behaviour" means no unexpected writes. The idea is that while "*(int*)(rand()) =3D 1;" is so bad that you can't predict anything, something as simple as a signed integer overflow can give the wrong answer but not launch nasal daemons. I don't know off-hand what compilers actually implement this - personally, I can't see that the standards give enough information to say what a compiler should do here. I also think the whole concept is wrong (for C /and/ for Ada) - it cannot possibly work. You can certainly say that signed arithmetic should always return either the correct answer (as defined by C), or an unspecified integer on overflow. (Or two's complement wrapped overflow if you prefer.) But if the code following it depends on having a valid and correct result from the arithmetic in order to avoid launching nasal daemons, then it is just as bad as launching them directly in the first place. (More realistically, imagine that the result of the overflowed operation is used as the offset to a pointer. Your "bounded undefined behaviour" just became "critical undefined behaviour" - and Ada will do exactly the same.) There is no way for a compiler to take undefined behaviour and produce "limited damage" code without the risk of causing just as much trouble later on. --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/ovrsik%244f0%241%40blaine.gmane.org. .