[poppler] Poor error handling in gmem.c

Florian Weimer fw at deneb.enyo.de
Thu Dec 8 15:14:08 PST 2005


* Albert Astals Cid:

> A Dijous 08 Desembre 2005 23:24, Florian Weimer va escriure:
>> With the recent merge from xpdf 3.01, problematic error handling code
>> has been introduced in to poppler:
>>
>> void *gmallocn(int nObjs, int objSize) {
>>   int n;
>>
>>   n = nObjs * objSize;
>>   if (objSize == 0 || n / objSize != nObjs) {
>>     fprintf(stderr, "Bogus memory allocation size\n");
>>     exit(1);
>>   }
>>   return gmalloc(n);
>> }
>>
>> Invalid input data (not just an out-of-memory condition) results in
>> the whole process being terminated, which is not a good thing to do
>> for a library.
> I agree, any suggestion?

You need to return an error code (NULL?) and check that in the
caller. 8-( Or simply throw an exception.  (I don't know how much you
rely on such C++ features.)

>> 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).

>> but this is best discussed with the xpdf folks.
> a) don't see why
> b) if you think that may i ask why you send that mail?

To point out the problem with the first function.  xpdf is not a
library, so the exit(1) call is not an issue there.


More information about the poppler mailing list