Re: Relying on exceptions in fuzz tests?
Nick <[email protected]>
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <[email protected]> |
I think the interesting point is that Chris is trying to run on a reduced environment that doesn't fully conform to the spec. That's very typical for embedded systems and older game consoles. Modifying the compiler or runtime in those situations is seldom desirable and possibly impossible. There might not even be signals available to trap exceptional conditions, so Chris' approach to ignore the test failures is probably the only viable option, as modifying OpenEXR to deal with such stripped environments seems way out of scope. He'll need to battle harden his application instead. Sent from my iPhone > On May 29, 2014, at 12:14, "Christopher Horvath" <[email protected]> wrote: > > I'm compiling OpenEXR with exceptions, but the libraries that I am required to link to beneath OpenEXR have the exception behavior disabled (inconsistently). > > I'm happy with the results that 2.1.0 passes all the regular tests for all the libraries. The fuzz tests don't work, but in my case, that's okay, I think. > > >> On Thu, May 29, 2014 at 12:12 PM, Brendan Bolles <[email protected]> wrote: >> On May 29, 2014, at 10:19 AM, Christopher Horvath wrote: >> >> > I'm in a crippled environment that explicitly disallows exceptions, and has modified underlying some (but not all) underlying libraries accordingly. >> >> >> Really the answer is that the OpenEXR library requires exceptions, just like it requires RTTI and other things. All the error handling is done with exceptions. If I turn off exceptions in gcc, I get an error wherever you see the keyword "throw". The library also never checks the result of a "new" operator because those are supposed to throw exceptions if they fail. >> >> So I guess you're going to have to start hacking your way to an exception-free version. >> >> >> Brendan > > > > -- > I think this situation absolutely requires that a really futile and stupid gesture be done on somebody's part. And we're just the guys to do it. > _______________________________________________ > Openexr-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/openexr-devel _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel