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 is a non issue when using gcc and clang unless one is using " -fshort-enums" [1]. Only switching to C++11 type safe enums can enforce size of enums in the standard. Personally, I don't like the choice of using fixed size integers instead of enums when the problem of predicable ABI is completely ignored everywhere else in the 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. As soon as you pushed for patch 2/5 I will rebase my patch series in a svn branch (Dominik gave me write access). [1] http://www.keil.com/support/man/docs/armclang_ref/armclang_ref_chr1411640303038.htm _______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
