<div dir="ltr">It's strictly better than leaving an assert/unreachable, since it's user input, not bad API usage.<div>I'm not very familiar with BitcodeReader's API, so in this case I would prefer to fix it right away, and later we could figure out how to make the API recoverable.</div><div><br></div><div>Although:</div><div>In this case, we can return something like -1, for now, making some callers skip over the thing or returning an error. The problem is: this is supposed to be an abbrev record. If you can't read one of its parts, what do you do?</div><div>Otherwise, I can make readRecord return an std::error_code, since most of its callers do the same, and propagate the error, since all of its callers (AFAICT) return an error_code too.</div><div><br></div><div class="gmail_extra"><div><div class="gmail_signature">  Filipe<br></div></div>
<br><div class="gmail_quote">On Fri, Jan 23, 2015 at 2:32 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In general, are we OK with suppressing AFL assertion failures by calling report_fatal_error? I don't think we should exit(1) when encountering invalid bitcode. The caller might want to do something else. The bitcode reader should ideally be architected to fail safely.<span class=""><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 23, 2015 at 2:16 PM, Filipe Cabecinhas <span dir="ltr"><<a href="mailto:filcab@gmail.com" target="_blank">filcab@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ok, I'll submit a patch to turn that into a report_fatal_error saying you can't start an abbrev with an array or blob.</div></blockquote></div></div></span></div>
</blockquote></div><br></div></div>