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