Hello Francesco, hello all,
> On 22 January 2019 at 23:16 Francesco Pretto <cez...@gmail.com> wrote:
> 
> 
> On Tue, 22 Jan 2019 at 22:27, Matthew Brincke <ma...@mailbox.org> wrote:
> >
> > I retract my acceptance of [PATCH 1/5] because I've found some
> > posts [1] to the mailing list which show that it's problematic
> > (non-portable at least, but can lead to crashes). I'll instead
> > change the signed type pdf_int8 to pdf_uint8 because I don't
> > think casting a possibly-negative value to an enum makes sense
> > (though of course I can't give credit for that).
> >
> >
> 
> No problem, but it's worth mention that usage of enum as instance
> member is already spread in the library, for example
> PdfParser::m_ePdfVersion, PdfEncrypt::m_eAlgorithm,
> PdfEncrypt::m_eKeyLength. I think having enum as instance member
... snip ...
> library. I would rather aim to fix it setting a sentinel 0xFFFFFFFF
> value of the enum so it will be at least 32 bit, basing on the fact
> that no compiler on earth will ever allocate more than 32 bit for
> an enum unless required by actual enum values (we shouldn't care
> about stupid compilers, really). This could be done with all the
> enums in the library.

the size of that member PdfVariant::m_eDataType was reduced to
8 bits to save RAM space because PdfVariant objects are abundant
when using PoDoFo, not so much with the other ones you mention.
Therefore I don't agree with your proposal. The commit of my
change has made svn r1959 [1], btw. For the other enums this
could be discussed further, also with the other committers.

Best regards, mabri

[1] https://sourceforge.net/p/podofo/code/1959/

Best regards, mabri


_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Reply via email to