<div class="gmail_quote">On Tue, Jan 31, 2012 at 12:44 AM, Abramo Bagnara <span dir="ltr"><<a href="mailto:abramo.bagnara@gmail.com">abramo.bagnara@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Il 31/01/2012 05:08, Richard Smith ha scritto:<br>
<div class="im">> Author: rsmith<br>
> Date: Mon Jan 30 22:08:20 2012<br>
> New Revision: 149344<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=149344&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=149344&view=rev</a><br>
> Log:<br>
> constexpr: catch a collection of integral undefined behaviors:<br>
>   -INT_MIN and INT_MIN / -1<br>
<br>
</div>Don't forget INT_MIN % -1. It is tied to INT_MIN / -1 in modern standards.<br>
</blockquote></div><br><div>I didn't forget it, but my interpretation of the standard is that it does not have undefined behavior.</div><div><br></div><div>In particular, [expr.mul]p4 says: "if the quotient a/b is representable in the type of the result, (a/b)*b + a%b is equal to a." This would presumably give INT_MIN % -1 undefined behavior, except that the antecedent is not met, so it does not apply. So we're left with INT_MIN % -1 being defined by "the binary % operator yields the remainder from the division of the first expression by the second", which is 0. I don't see where the standard would require that the division itself fit within the relevant type.</div>
<div><br></div><div>- Richard</div>