[llvm] r263742 - Bitcode: Error out instead of crashing on corrupt metadata
David Blaikie via llvm-commits
llvm-commits at lists.llvm.org
Thu Mar 17 15:27:40 PDT 2016
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.
> > 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 &
> > as part of the fuzzer's seed library (whatever the right word is for
> 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
> If we don't add checks for broken files, refactoring to, for example,
> use TypedError will not be as easy.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits