<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 9, 2016 at 2:06 AM, David Chisnall via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9 Nov 2016, at 07:55, Stephan Bergmann via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> What I observe with various versions of Clang:<br>
><br>
>> $ cat test.cc<br>
>> #include <iostream><br>
>> int main() {<br>
>>    char a[1/0];<br>
>>    std::cout << sizeof a << '\n';<br>
>> }<br>
>><br>
>> $ clang++ -Weverything test.cc<br>
>> test.cc:3:11: warning: variable length arrays are a C99 feature<br>
>>      [-Wvla-extension]<br>
>>    char a[1/0];<br>
>>          ^<br>
>> test.cc:3:11: warning: variable length array used [-Wvla]<br>
>> 2 warnings generated.<br>
>><br>
>> $ ./a.out<br>
>> 0<br>
><br>
> Is there a specific reason to not emit a warning/error about the undefined behavior in evaluating the constant bounds expression, 1/0?<br>
<br>
</span>I believe that the issue here is that 1/0 is *not* a constant expression, it is undefined behaviour (typically, run-time trap).  We probably should have a special return value for attempting to evaluate something that should be an ICE and finding that the result is undefined, which would allow this to become a more helpful error along the lines of ‘array length is an undefined value, this will abort at run time’.<br>
<br>
Currently, I believe that the undefined value is simply marked as something that can not be evaluated at compile time and so this is equivalent to:<br>
<br>
int foo(int d)<br>
{<br>
  char a[1/d];<br>
<span class="">  std::cout << sizeof a << '\n';<br>
}<br>
<br>
</span>This is valid code when d > 0, but if d == 0 it will likely trap.<br>
<br>
David<br></blockquote><div><br></div><div>A constant expression that would give undefined behavior is ill-formed, and the compiler is required to issue a diagnostic.  It does, by default, but the diagnostic is misleading and doesn't identify why the code is ill-formed.  So it's not formally a violation of the C++ standard, but it's not a good error message.  Compiling the code and acting as if 1/0 was 0 is also fairly dubious (though again, not a violation of the C++ standard, which only requires a diagnostic and never forbids producing an executable).</div><div><br></div><div>-- James</div></div></div></div>