[poppler] Poor error handling in gmem.c
m_kretzschmar at gmx.net
Mon Dec 12 03:16:00 PST 2005
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
More information about the poppler