>I got your point. >The problem is that we received zero-size only when running verifier >with a low-mem simulation. >It's not a normal situation, but our code isn't ready for this case. >Take into account that only "problemmatic" calls to >ExAllocatePoolWithTag were replaced; i.e all call were chances to get >zero-size > 0. >ASSERT may be good for a check version, but I don't believe we can find >and eliminate all the problemmatic cases by doing so.
IMO, this is too broad of a fix and in the wrong place. Replacing standard Windows calls with a macro that looks like a Windows call just obscures what's happening and increases maintenance costs. At this point, we don't know if the call to malloc is wrong, or if some other value is being returned to the code that calls malloc incorrectly. I would expect a fix for a low-memory situation to add a check that malloc worked, versus a check to see if malloc is called with a size of 0. To me, this is pointing to an issue in some other piece of code that isn't being modified by this patch. - Sean _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
