<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Sep 11, 2017 at 3:31 PM Greg Clayton via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org">lldb-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I know there are two points of view here so I will give my two cents:<br>
<br>
If it comes down to something as easy as "always check for NULL before doing something", or something that is similar and very easy, I would say just code around it. Don't "assert(...)" or "llvm_unreachable(...)". Things that fall into this category: switch statements with defaults that might catch things, checking var/ivar for NULL, seeing if a collection is empty, bounds checking things.<br>
<br>
One example here is LLDB has its own object file readers for mach-o and ELF. Mach-o has load commands in the file header and each load command has a "cmd" uint32_t whose value is an enum. It is followed by a uint32_t "length" of this data. The LLVM version of the mach-o file parser, a while back before changes were made, wanted to assert or llvm_unreachable for any load command that it didn't recognize. This kind of thing can't happen in a debugger. </blockquote><div><br></div><div>Right, but that's user input.  On the other hand, suppose LLDB manually constructs some IR that it passes to the interpreter.  Since LLDB is in full control of the IR it generates, it can safely assert that the interpreter was successful at interpreting it.</div></div></div>