<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Unable to read cross-reference streams with 8-byte offsets" href="https://bugs.freedesktop.org/show_bug.cgi?id=56318#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Unable to read cross-reference streams with 8-byte offsets" href="https://bugs.freedesktop.org/show_bug.cgi?id=56318">bug 56318</a> from <a class="email" href="mailto:Thomas.Freitag@alfa.de" title="Thomas Freitag <Thomas.Freitag@alfa.de>"> Thomas Freitag</a> <pre>(In reply to <a href="show_bug.cgi?id=56318#c5">comment #5</a>) > Thomas are you sure Guint is 64 bits? That's not true on my my Linux 64 bits > box, is that a windows thingie? Oh, oh, of course You're true: int has 32 bits in 32 bit AND 64 bis environments (with the compiler and architecture I know). I mixed that already up (gaving int the wrong size) when had to change 16-bit-libraries so that they could run in a 32-bit environment. Long long ago, but really a déjà vu. So what to do with this PDF, where the high 32 bits are zero? Should we test for overflow with an error message "Large files not supported" but accept it when the high 32 bit are zero? Wait that somebody implements large file support? Or just commit the patch knowing that we run into problems with really large files?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>