Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: In the end, rason will come Date: Wed, 31 Jul 2019 13:05:40 -0700 Organization: None to speak of Lines: 53 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="7781664425e815c5ebc16d9aaed99279"; logging-data="2609"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/NdcZNkmjr2S+StE69hNcA" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:RLSZos5Texa6qjns5IzjVkFLRx4= sha1:XhTXJIztPiLQr6d3BhBBoPN8MPc= Xref: csiph.com comp.lang.c++:67229 Öö Tiib writes: > On Wednesday, 31 July 2019 11:14:17 UTC+3, Bonita Montero wrote: >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html The link is to: p0907r0 Signed Integers are Two’s Complement Published Proposal, 9 February 2018 > This feels like two major proposals. One is that all signed integers > should be two's complement and other is that signed integer overflow > should wrap. > > Majority will be happy (or at least content) with both but about > second there will be likely a bit of opposition and controversy. > > Most of such opposition will boil down to claim that signed > arithmetic should not overflow anyway in sane code and therefore > some optimizations where compiler did assume that it does not > overflow will be lost without any gain. > > I agree that that signed arithmetic should not overflow > in good code but it seems hard to find (or to teach) programmers > who write good code in that respect. So there are often bugs with > it and so I would often prefer crash (or have SIGFPE raised) > instead of wrapping. I have no particular objection to requiring two's complement for signed integers. I don't think this proposal addresses padding bits or the possibility that the most negative representation is a trap representation, so would still be some rare variations to worry about. Specifying wrapping behavior for signed integers could be a *big* problem. In particular, this: int n = INT_MAX + 1; would probably not produce a warning. It's not required to do so now, and compilers could produce warnings anyway, but making INT_MAX + 1 well defined where it's currently almost certainly an error would be confusing. More concretely, this: constexpr int n = INT_MAX + 1; is currently invalid and would become legal. Requiring 2's-complement representation while leaving overflow behavior alone would be a simpler and less controversial change. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */