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

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

Re: In the end, rason will come

Show all headers | View raw

Öö Tiib <ootiib@hot.ee> writes:
> On Wednesday, 31 July 2019 23:05:52 UTC+3, Keith Thompson  wrote:
>> 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.
>
> I feel confused, either I misunderstand the point you are making
> or have misread standard.
> Right now (as with C++17) the std::numeric_limits<int>::is_modulo
> has implementation-defined constexpr value. Yes? 
> That value can depend on compiler options if it is true
> or false. Yes?
> My reading of standard is that when it is true then INT_MAX + 1
> is not undefined behavior. Do I misread?
> Are you saying that it should be undefined behavior?
> I read that the proposal was to make it true always and that I'm
> also unsure if it is good idea.

As far as I know, that's all correct.

I hadn't known about is_modulo.

For g++ and clang++, is_modulo is false for signed integer types, which
makes the behavior of INT_MAX + 1 undefined.  I don't know whether
there's an option that makes it true, or what other implementations do.

Yes, that does affect the issue.  The proposal would effectively require
is_modulo to be true for signed types.

It would be nice to have a way for a programmer, not just an
implementation, to decide whether a given signed type has wraparound or
overflow semantics.  That's probably beyond the scope of this proposal.

-- 
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