On Tue, 2017-02-28 at 00:14 +0100, Matthew Brincke wrote:
> I haven't completed testing yet
Hi,
thanks for the patch. Just from a quick read of the proposed change:
> + const pdf_int64 maxNum
> + = static_cast<pdf_int64>(std::numeric_limits<long>::max());
As far as I know, 'long' type is architectural dependant, 32 bits on
32bit arch and 64 bits on 64bit arch, thus it produces different
values. Avoiding a 'long' usage might be a general benefit.
> + "(%ld)!\n",
> + nFirstObject + nNumObjects, m_nNumObjects ); // 2nd arg is
> long!
The %ld is incorrect for the same reason. There are defines for proper
formats, or cast the second argument to pdf_int64 instead and use the
format specifier as before.
> + ") in this XRef table than supported by this version of PoDoFo, "
This sounds odd to me, are you sure it's about what PoDoFo supports,
not about what the standard supports? I mean, the standard suggests to
stay in those limits even if the writer runs on a system which can
cover more objects, to be compatible with 32-bit systems (because you
never know on which system the reader runs).
Bye,
zyx
--
http://www.litePDF.cz i...@litepdf.cz
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
