Hi zyx, hi all,
> zyx <z...@litepdf.cz> has written on 28 February 2017 at 08:38:
>
>
> 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.
sorry that I haven't explained myself enough, I know this, it's just
that moving m_nNumObjects away from being a 'long' would risk breaking
binary compatibility which I'd like to avoid in a security update like this
(it is one, it is proposed for fixing one or two CVEs).
>
> > + "(%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.
AFAIK %ld is the format specifier fitting to a value of type 'long' regardless
of what that actually is. If that should be wrong, please point me to an
(online,
free) reputable source. If you'd like me to get rid of the 'long' (probably)
sacrificing binary/ABI compatibility please say so explicitly. If not, please
consider testing the patch further (see also below).
>
> > + ") 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).
By the Robustness Principle/Postel's Law ("Be strict in what you send,
but generous in what you receive") I wanted to hint at PoDoFo maybe going to
support more objects than what the standard suggests (!) for 32-bit systems
when those were rather more common than now, in the future (on systems on which
a 'long' is wider than 32 bit, of course).
This is under the assumption PoDoFo's PdfParser is only used for analyzing,
not actually creating/modifying PDF (so that your last parenthetical doesn't
apply here), please point out if I'm wrong.
> Bye,
> zyx
Best regards, mabri
>
> --
> 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
