Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c++
Subject: Re: In the end, rason will come
Date: Wed, 31 Jul 2019 16:32:03 -0700
Organization: None to speak of
Lines: 47
Message-ID: <lnr2653hn0.fsf@kst-u.example.com>
References: <qhrike$89j$1@news.albasani.net> <e04142c6-83a1-4b9d-835e-d41f5f138643@googlegroups.com> <lny30e2cmj.fsf@kst-u.example.com> <ec0c8c75-2523-4318-9261-b1cf42fc6399@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="19a7d2ffb50b573895ac49d3ff2dfaf6"; logging-data="20623"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19e/SpJ/OcaKMMNqL8SZVZU"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:HmZlYHaPJXTTP5Dmn2aZxOeVxwo= sha1:cDHeYC16qbMRoZ0P72BziwamFtk=
Xref: csiph.com comp.lang.c++:67234

Öö 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 */