<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 22, 2016 at 8:57 AM, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">




<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;background-color:rgb(255,255,255)"><div><div class="h5">
<p><span style="font-size:12pt;color:rgb(33,33,33)">>On Fri, Jan 22, 2016 at 8:27 AM, George Rimar
</span><span dir="ltr" style="font-size:12pt;color:rgb(33,33,33)"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span><span style="font-size:12pt;color:rgb(33,33,33)"> wrote:</span></p>
</div></div><div style="color:rgb(33,33,33)">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;background-color:rgb(255,255,255)">
<span>
<p><span style="color:rgb(33,33,33);font-size:12pt">>></span><span style="color:rgb(33,33,33);font-size:12pt">This should probably be written with an assert instead:</span><br>
</p>
</span>
<div style="color:rgb(33,33,33)">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span>
<div>>></div>
<div>> > assert((!this->Sec || this->Sec == Sec) && "multiple .eh_frame sections ....");</div>
<div>>  <br>
</div>
</span>> This should never happen, and if will due to a bug or something then result is completely unknown, because<br>
</div>
<div class="gmail_quote">> code does not suppose that. So it is fatal error actually.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>> </div>
<div>>If it's never meant to happen (if it does happen, it's a programmer error) then that's entirely appropriate for an assertion.</div>
<div>> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;background-color:rgb(255,255,255)">
<div style="color:rgb(33,33,33)">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">> That why I think unreachable fits better than assert and also t<span style="font-size:12pt">here is no asserts in release usually.</span></div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>> </div>
<div>> That's correct - assertions are used to test for programmatic errors/mistakes.<br>
><br>
> unreachable is roughly equivalent - if not worse, with unreachable, in an -O0 build the unreachable behaves something like an assert (the program will fail hard, print an error, > etc) but in anything else, LLVM will optimize assuming the condition is true.
 This means if the condition is not true, the behavior may be worse than just continuing without > having done anything. LLVM will deduce that the condition /must/ be true.<br>
> <br>
> - Dave<br>
</div>
<div><br>
</div>
</div></div><div>So If we have unreachable it will work as assert for us here for all cases except release with optimizations. Then if we realy want to be safe then its probably better to call error() here to cover everything. I dont think that assert is better in case
 of -Ox because code just does not support that case, it can crash or hang or whatever, I dont know what will be and assert is not better for "final" release here because will be just skipped.</div></div></div></div></div></div></div></blockquote><div><br></div><div>I think we're talking past each other a bit, and I'm not quite sure how to resolve the disconnect here, but I'll try.<br><br>The general idea is that code shouldn't be written to be resilient to programmer errors - once invariants and preconditions have been violated, there's really nothing we can do anyway. Also, we don't want to spend time checking all these invariants and preconditions in release builds (because we want the compiler to be fast). So we use assertions and unreachable, rather than conditionals and error handling/reporting for cases that are not intended to be possible. ( <a href="http://llvm.org/docs/CodingStandards.html#assert-liberally">http://llvm.org/docs/CodingStandards.html#assert-liberally</a> discusses some of this)<br><br>In short, if this case is only reachable by a programmer error, it should be an assert. (unreachable is used when it's a block of code that can't be reached - like a default in a switch, the end of a function that has some algorithmic reason to always return through some other path, etc - this is discussed in the coding standard linked above)</div></div></div></div>