Are you saying you have a malloc implementation that crashes if it can't allocate due to not enough memory? Or are you saying that the fuzz test relies on an exception not a nullptr test? If the latter it would be better to modify the test to null test. If the former, what the heck?
Fuzz tests generally are supposed to demonstrate that the library can survive malicious exploits like forced overruns or whatever through malformed files. If you are crashing, it's a bad malloc, a bad test, or OpenEXR isn't completely fuzz safe. Or this is a different use of the term fuzz testing that I am not familiar with ;) - Nick Sent from my iPhone > On May 28, 2014, at 15:01, "Christopher Horvath" <blackenc...@gmail.com> > wrote: > > Hey Folks, > > It seems like some of the fuzz tests are explicitly attempting to fail by > creating large allocations and catching exceptions from failed memory > allocations. If you're working with a malloc library that has exceptions > turned off, this causes crashes... > > Is this the correct interpretation of how fuzzScanLines & fuzzFile is > intended to work? > > This seems to be testing that malloc throws correctly - which in my case, it > does not - I just want to make sure I can feel comfortable turning these fuzz > tests off for the future. > > Chris > > -- > 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 > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
