That could be because "new" is defined in the language as throwing an exception if it fails to allocate memory. Doing a NULL check after "new" would only be necessary if running in a crippled environment that does not support exceptions.
Malloc/calloc/realloc should never throw, but return NULL if they fail to allocate memory. Chris On 5/28/14 11:57 PM, "Peter Hillman" <pet...@wetafx.co.nz> wrote: > > The OpenEXR fuzz tests insert bytes into files to test what happens with > accidentally or maliciously damaged files. > When a "length-of-attribute" field in the EXR Header is modified to be > an extremely large number, the library will often attempt to allocate a > large amount of memory to load the supposedly large attribute. There's > no standard place where this happens; each attribute type manages > loading the values itself. The field storing type of the attribute may > also become damaged, causing unusual behaviour. > > It seems like the OpenEXR library does rather assume that calls to 'new' > etc will throw exceptions if they fail, rather than nullptr testing. > This is in the library itself, rather than the fuzz tests. > > > > > > On 29/05/14 13:26, Nick wrote: >> 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 > > > _______________________________________________ > 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
