<div><br><div class="gmail_quote"><div dir="auto">On Mon, Mar 12, 2018 at 13:32 Lawrence Crowl <<a href="mailto:Lawrence@crowl.org">Lawrence@crowl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3/12/18, Myria <<a href="mailto:myriachan@gmail.com" target="_blank">myriachan@gmail.com</a>> wrote:<br>
> The severity of the current situation is that I generally avoid signed<br>
> integers if I intend to do any arithmetic on them whatsoever, lest the<br>
> compiler decide to make demons come out of my nose.<br>
<br>
So why not specify the option to turn on trapping?<br>
<br>
> And even then, I'm not safe:<br>
><br>
> std::uint16_t x = 0xFFFF;<br>
> x *= x; // undefined behavior on most modern platforms<br>
<br>
How? The C++ standard defines unsigned arithmetic as<br>
modular arithmetic.<br>
</blockquote><div dir="auto"><br></div><div dir="auto">But that's the catch: it's double secret signed arithmetic. The promotion rules of C, inherited by C++, state that on any arithmetic operation, integer types of rank less than int promote to int. This promotion is regardless of signedness.</div><div dir="auto"><br></div><div dir="auto">On a "typical modern platform", std::uint16_t is unsigned short. That is of lesser rank than signed int, so it promotes to signed int on any arithmetic operation, resulting in the following:</div><div dir="auto"><br></div><div dir="auto">int promoted_x = x;</div><div dir="auto">x = static_cast<std::uint16_t>(promoted_x * promoted_x);</div><div dir="auto"><br></div><div dir="auto">65535 * 65535 overflows a signed int on a typical 32-bit int platform, which is undefined behavior.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
More importantly, what happens to your program when x*x < x?<br>
</blockquote><div dir="auto"><br></div><div dir="auto">The code that led me to finding this was a 16-bit variant of the FNV hash function, so it worked properly after the correct casts were added to allow the wrap.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>> My code has to do silly things like this in order to safeguard against<br>
> such potential compiler abuses:<br>
><br>
> typedef decltype(std::uint16_t() + 0u) promoted_uint16;<br>
<br>
How does this typedef help?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div dir="auto"><br></div><div dir="auto">Arithmetic between any unsigned type and unsigned int results in a type of at least the first type's size that cannot be promoted to a signed type in arithmetic with other unsigned types.</div><div dir="auto"><br></div><div dir="auto">It's like uint16_fast_t, except that it guarantees that all operations performed will be well-defined to wrap, with just the inconvenience of potentially being larger than the actual intended type.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> I would be happy if an option like -fwrapv were supported everywhere,<br>
> but Visual Studio doesn't have such an option, and Microsoft has<br>
> already denied requests for such an option to be implemented.<br>
<br>
What about -ftrapv?<br></blockquote><div dir="auto"><br></div><div dir="auto">If I were working on something where signed int overflow were a problem, then sure, in debug builds. In release builds, I wouldn't use that for performance reasons (except where it's mostly free, like on MIPS).</div><div dir="auto"><br></div><div dir="auto">Melissa</div></div></div>