The severity of the current situation is that I generally avoid signed
integers if I intend to do any arithmetic on them whatsoever, lest the
compiler decide to make demons come out of my nose. And even then,
I'm not safe:

std::uint16_t x = 0xFFFF;
x *= x; // undefined behavior on most modern platforms

My code has to do silly things like this in order to safeguard against
such potential compiler abuses:

typedef decltype(std::uint16_t() + 0u) promoted_uint16;

I would be happy if an option like -fwrapv were supported everywhere,
but Visual Studio doesn't have such an option, and Microsoft has
already denied requests for such an option to be implemented.

On Mon, Mar 12, 2018 at 12:37 PM, Lawrence Crowl <Lawrence_at_[hidden]> wrote:
> On 2/18/18, Myria <myriachan_at_[hidden]> wrote:
>> C and C++'s main competitors all either define signed overflow as
>> wrapping or define it as trapping. Some do both, allowing the
>> programmer to choose situationally.
>>
>> None of these languages leave it undefined to allow the
>> compiler/interpreter to assume that it cannot happen - it's rather
>> unique to C and C++.
>
> The C++ wording "the program has undefined behavior" maps to the Ada
> wording "the program is erroneous". Plenty of languages have aspects
> of their definition in which it is possible for a program to violate
> sactioned assumptions of the implementation.
>
> The C++ standard is not the only constraint on implementations. In
> particular, you as a customer can ask your vendor to not use a
> sanctioned assumption.
>
> The problem we have encountered recently derives from one or more
> implementations have started using an assumption that they never
> used before, WITHOUT ISSUING WARNINGS.
>
> Finally, the 'undefined behavior' label permits the implementation to
> implement trapping, wrapping, or something else. Some provide options
> to specify that behavior.
>
>> Most of these languages are considered "safer", too.
>
> That safety may be more perceived than real. With the proper tools,
> more undefined behavior (aka more programs being erroneous) enables
> identifying incorrect program behavior. Standard must accept that
> some programs are wrong before any tool can identify wrong programs.
>
>> The origins of leaving the behavior undefined are because weird
>> things happen on non-two's-complement machines.
>
> Not wierd, just different. I agree that different representations
> was the original motivation. However, even with a defined two's
> complement representation, but we should not miss the opportunity to
> help programmers identify bad code.
>
> --
> Lawrence Crowl
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub