Re: [boost] Current Guidance on Compiler Warnings?

Subject: Re: [boost] Current Guidance on Compiler Warnings?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-11-27 19:59:36

On 11/27/18 10:31 PM, Steven Watanabe via Boost wrote:
> On 11/27/2018 11:58 AM, Andrey Semashev wrote:
>> On Tue, Nov 27, 2018 at 7:18 PM Steven Watanabe via Boost
>> <boost_at_[hidden]> wrote:
>>> On 11/26/2018 03:57 PM, Gavin Lambert via Boost wrote:
>>>
>>> <snip>
>>> The most important feature of undefined behavior is that it
>>> allows you to choose the behavior that you want instead of
>>> hard-coding it into the program.
>>
>> I disagree. I think, the choice is only there as long as you target a
>> specific language implementation, or the very few of them which offer
>> the choices you care about. If you're trying to write portable code,
>> like we most often do in Boost, for example, you really don't have a
>> choice and have to assume the behavior is really undefined.
> 
> You don't "assume that it's undefined."  It /is/ undefined.

Sure, that's my point. I was merely pointing out that there's no 
"choice" to make.

> A correct C++ program should never do it.

I wouldn't assume about user's code.

>> And this
>> is the worst thing because it is a constant source of bugs and is not
>> useful to the programmer.
> 
> My point is that it's a bug regardless.  Your
> program is wrong regardless of whether it's
> formally undefined behavior or just gives the
> wrong answer.  The only difference is in how
> serious the symptoms are and what tools are
> available for finding the problem.

Having the wrap semantics would be useful, at least for being able to 
portably detect an overflow. That ability alone allows to implement 
whatever other behavior you might need. OTOH, having overflow undefined 
doesn't allow you to do anything with it.

>> The ironic thing is that you can't even
>> check for a possible overflow in portable C++ since "it doesn't
>> happen" by the language rules and the compiler is allowed to subvert
>> or completely discard your checks.
> 
> That only happens if you write the check incorrectly.

Until the language mandates two's complement signed integers (in the 
yet-to-come C++20), I don't think there is a correct way. At least 
nothing easy enough comes to mind.