<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 11, 2013 at 11:16 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<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">

Even when you have a !NDEBUG build, the platform assert() is pretty<br>
crummy on Windows and generates, at best a UTF-16 dump, or sometimes<br>
just pops up a dialog.</blockquote><div><br></div><div>Agreed.  We have lots of hacks surrounding this.  See LLVM_DISABLE_CRASH_REPORTING in lib/Support/Windows/Signals.inc.  I've also had to change ninja to pass through UTF-16 output from Clang assertion failures.</div>
<div><br></div><div>Having our own error reporting would be nice for Windows, but it would take us further away from standard C library features.  We're already using llvm_unreachable everywhere, so this might not be so bad.</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">WebKit and other projects take the same approach<br>

and define their own assertion macros to deal with this portably.<br>
<br>
So as far as I can tell, as long as the headers use assert(), they need<br>
to use our own version in order for the definition to match.<br></blockquote><div><br></div><div><div>Even though I brought it up, the ODR problem feels small enough to skate by without worrying about it.  The typical use case for embedders is to turn off NDEBUG so they can debug, which means LLVM's cast<> implementation might get slow if the linker picks the wrong definition to call from LLVM libs.</div>
</div></div></div></div>