[poppler] Poppler 0.21.0 (0.22 Alpha) released

[Hib Eris]

Hi Albert,

On Wed, Oct 3, 2012 at 8:29 PM, Albert Astals Cid <aacid at kde.org> wrote:
> El Dissabte, 22 de setembre de 2012, a les 15:55:21, Hib Eris va escriure:
>>
>> I compiled 0.21 and got one new warning, which I think might cause a
>> buffer overflow.
>> I am not sure though.
>
> Is this really correct? If you have a char that is signed with -1, casting it
> to unsigned will give you what? and will that be the array we want?

Current code does a pdfDocEncoding[-1] which points you to an address
before the start of the array, that seems incorrect to me.

Casting -1 to unsigned gives you 255. pdfDocEncoding is an array of
length 256, so pdfDocEncoding[(unsigned char)-1] = pdfDocEncoding[255]
will point to the last element of that array. Is this correct? I do no
know for sure, but a grep on the source:

$ find -name "*.cc" | xargs grep 'pdfDocEncoding\['
./utils/pdfdetach.cc:          u = pdfDocEncoding[s1->getChar(j) & 0xff];
./utils/pdfdetach.cc:          u = pdfDocEncoding[s1->getChar(j) & 0xff];
./utils/pdfdetach.cc:          u = pdfDocEncoding[s1->getChar(j) & 0xff];
./utils/pdftohtml.cc:        unicodeString[i] =
pdfDocEncoding[rawString->getChar(i) & 0xff];
./utils/pdftotext.cc:	u = pdfDocEncoding[s1->getChar(i) & 0xff];
./glib/poppler-document.cc:      ucs4_temp[i] =
pdfDocEncoding[(unsigned char)s->getChar(i)];
./poppler/UTF.cc:      u[i] = pdfDocEncoding[s[i]];
./poppler/PDFDocEncoding.cc:Unicode pdfDocEncoding[256] = {
./poppler/Outline.cc:	title[i] = pdfDocEncoding[s->getChar(i) & 0xff];
./poppler/Annot.cc:        uChar = pdfDocEncoding[text->getChar(*i) & 0xff];
./poppler/Form.cc:    Unicode u = pdfDocEncoding[(unsigned
int)((unsigned char)cstring[j])]&0xffff;

suggests that we do either '& 0xff' or cast to (unsigned char), except
for in UTF.cc.
Casting with (unsigned char) and '& 0xff' give the same result as far
as I can see.

Cheers,
Hib Eris