Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #67229

Re: In the end, rason will come

Show all headers | View raw

Öö Tiib <ootiib@hot.ee> 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  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

In the end, rason will come Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-31 10:14 +0200
  Re: In the end, rason will come "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-07-31 01:25 -0700
    Re: In the end, rason will come James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-07-31 07:58 -0400
      Re: In the end, rason will come Siri Cruise <chine.bleu@yahoo.com> - 2019-07-31 05:14 -0700
      Re: In the end, rason will come Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-07-31 22:35 +0000
    Re: In the end, rason will come "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-07-31 14:59 +0200
  Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 03:48 -0700
    Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-07-31 15:29 +0200
      Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 14:22 -0700
        Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-01 23:25 +0200
          Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-08-01 19:53 -0700
            Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-02 20:46 +0200
              Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-08-05 02:56 -0700
                Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-06 14:32 +0200
                Re: In the end, rason will come Manfred <noname@add.invalid> - 2019-08-07 16:05 +0200
                Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-07 17:00 +0200
                Re: In the end, rason will come "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-07 18:39 +0200
                Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-07 21:15 +0200
                Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-07 21:20 +0200
                Re: In the end, rason will come Ralf Goertz <me@myprovider.invalid> - 2019-08-08 12:14 +0200
                Re: In the end, rason will come Ralf Goertz <me@myprovider.invalid> - 2019-08-08 12:21 +0200
          Re: In the end, rason will come Christian Gollwitzer <auriocus@gmx.de> - 2019-08-02 07:41 +0200
    Re: In the end, rason will come Keith Thompson <kst-u@mib.org> - 2019-07-31 13:05 -0700
      Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 15:48 -0700
        Re: In the end, rason will come Keith Thompson <kst-u@mib.org> - 2019-07-31 16:32 -0700
          Re: In the end, rason will come Öö Tiib <ootiib@hot.ee> - 2019-07-31 19:21 -0700
      Re: In the end, rason will come Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-02 08:10 +0200
  Re: In the end, rason will come David Brown <david.brown@hesbynett.no> - 2019-08-06 14:54 +0200

csiph-web