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