[llvm] r263742 - Bitcode: Error out instead of crashing on corrupt metadata

[David Blaikie via llvm-commits]

On Thu, Mar 17, 2016 at 3:19 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 17 March 2016 at 15:11, David Blaikie via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> > Yeah, if we're going to get into the business of making bitcode robust to
> > arbitrary errors, we really should talk about a testing strategy for it.
> I
> > imagine that'll probably look like a fuzzer (as mentioned in review) and
> > we'll just pull out cases from the fuzzer to check in as test cases &
> keep
> > as part of the fuzzer's seed library (whatever the right word is for
> that).
>
> I don't think a fuzzer is sufficient.
>

A fuzzer's the only way we're likely to find all the cases - but, yes, once
we identify and fix a case, we would move teh minimal/reduced fuzzer case
into a corpus in our regression test suite (most fuzzing cases are pretty
small - the big ones, well we tend not to checkin big tests for non-fuzzy
issues these days already, so I think we'd just live with those gaps or put
them in the test-suite proper) alongside all our usual regression tests.


>
> In any other area I can refactor code and have a pretty good
> confidence with just check-all that I at least haven't regressed
> anything.
>
> If we don't add checks for broken files, refactoring to, for example,
> use TypedError will not be as easy.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160317/184d6909/attachment.html>