[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