> I don't know if you already solved the problem, but after some digging I > found that the following is happening in the function > lzw_buffer_get_code in pdf-stm-f-lzw.c > > b->valbuf is an unsigned long, and b->valbits seems to assumes this is > 32 bit in size (from what I can make of it). On x86-64 however, unsigned > long is 64 bit. > > When I compile with option -m32 (which sets unsigned long to 32 bit), > the problem disappears. Also, setting the type of b->valbuf to unsigned > solves the problem (all tests pass). >
Thanks a lot for looking at the code, I had not tried to fix this yet :p It is true that the implementation is lacking proper different support for different bitwise machine-representations. To use the pdf_[i|u](32|64)_t data types instead of int or long would help a lot to avoid this kind of problems. Would be possible to make the filter to use the fixed-wide data types? -- Jose E. Marchesi <[email protected]> http://www.jemarch.net GNU Project http://www.gnu.org
