[poppler] Poor error handling in gmem.c

[Martin Kretzschmar]

As far as I remember, the whole raison-d'etre of gmallocn is to detect 
overflows in the nObjs * objSize expression. xpdf 3.00 was simply using 
gmalloc and the product expression to allocate memory. In some places 
nObjs was user supplied data, so a pdf file could cause an overflow. 
Then, in 3.00patchSomething, the product was checked for overflow in a 
few places (by doing the n / objSize == nObjs check). Now it's a 
separate function that used consistently (I hope).

Florian Weimer schrieb:
>>>The gmallocn function is also incorrect because according to the C
>>>standard, the if condition can be assumed to be always false, 
>>
>>The oh magnificient C standard mandates a int can never be zero? 
> 
> 
> Okay, it's equivalent to "if (objSize == 0) ...".  My fault.
> 
> 
>>The oh magnificient mandates computer architectures don't have
>>limits so there are never overflows in variables?
> 
> 
> The C standard simply doesn't tell you what happens in this case, and
> C compilers are free to use this to perform additional optimizations
> (because they can assume that signed integer overflow cannot happen).

Are you saying that gcc analyzes the code with n = nObjs * objSize; n / 
objSize and optimizes away what in the end looks like nObjs != nObjs? Is 
it really allowed to do that? If yes, a different check should be placed 
here instead.


Regards,

Martin