On 02/11/13 16:46, Ian Lance Taylor wrote:
But those cases are passing 1 to vec_safe_reserve, which in turn
passes 1 to calculate_allocation, so calculate_allocation can not
return 0, so vec_reserve can not return NULL.
At least that is how it seems to me.
Yes, you're right. I got too deep into looking at just what was visible
in the preprocessed code (c-common I think) and didn't look at
calculate_allocation from vec.c.
So this a false positive for my null pointer dereference checker.
There's nothing to propagate the fact that calculate_allocation can not
return null if reserve is > 0.
This is also a good example of code which can be improved by isolating
the unexecutable paths where the calls to vec_safe_reserve return NULL.
Thanks for the sanity check...
Jeff
