diff options
| author | Robin Watts <robin.watts@artifex.com> | 2015-05-15 12:54:59 +0100 |
|---|---|---|
| committer | Robin Watts <robin.watts@artifex.com> | 2015-05-15 13:44:41 +0100 |
| commit | 86f62075afa178b222e6bc0f9fdc79f82d441df0 (patch) | |
| tree | 82d0a09ed111cba76f3cfad5331299fb6b5fa32b /source/pdf | |
| parent | f671c582bd62f65ee036f505d75841c15a5ecec3 (diff) | |
| download | mupdf-86f62075afa178b222e6bc0f9fdc79f82d441df0.tar.xz | |
Fix bug in pdf_dict_find.
Sebras and Tor spotted that we could get occasional 'warning: cannot seek
backwards' messages. An example command that shows this is:
mutool show pdf_reference17.pdf grep
They further tracked the problem down to the 'sorted' side of the
pdf_dict_find function.
In the binary search, I calculate c to be the comparison value between
pairs of keys. In the case where both keys (names) are in the special
case 'known' range below PDF_OBJ__LIMIT, I use pointer arithmetic for
this. Unfortunately, I was forgetting that the compiler thinks that
pdf_obj *'s are 4 (or 8) bytes in size, so was doing (a-b)/4.
To workaround this I cast both keys to char *'s. This solves the bug.
Thanks to Sebras and Tor for doing the hard work in tracking this down.
Diffstat (limited to 'source/pdf')
| -rw-r--r-- | source/pdf/pdf-object.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/source/pdf/pdf-object.c b/source/pdf/pdf-object.c index f0415e98..0ebff26d 100644 --- a/source/pdf/pdf-object.c +++ b/source/pdf/pdf-object.c @@ -1083,7 +1083,7 @@ pdf_dict_find(fz_context *ctx, pdf_obj *obj, pdf_obj *key, int *location) int c; k = DICT(obj)->items[m].k; - c = (k < PDF_OBJ__LIMIT ? key-k : -strcmp(NAME(k)->n, PDF_NAMES[(intptr_t)key])); + c = (k < PDF_OBJ__LIMIT ? (char *)key-(char *)k : -strcmp(NAME(k)->n, PDF_NAMES[(intptr_t)key])); if (c < 0) r = m - 1; else if (c > 0) |