Hi Jeff, > Below is a list of functions of interest relating to pdf_i64_t from > http://gnupdf.org/Lib:API_Consistency_Report. I believe they make up > the public functions exposed by pdf-type.h/pdf-type.c. > > The items with an asterisk (*) are not used. In general, they are a > pdf_i32_t variant of the 64 bit function. > > Can the functions with an asterisk be removed? If the functions are > not 'code proliferation' added over time, I will write test cases for > them.
No, we shouldn't remove them. They may not be used in the base layer, but they may be used in upper layers. > > If the functions with asterisks are part of the official API, should > all functions have a <fn>_i32 variant for consistency? For example, > pdf_i64_abs_i32 and pdf_i64_neg_i32. Not really. Those functions with a _i32 suffix are operations to be done in a pdf_i64_t variable, using an additional i32 variable in the operation. For example, you may add an i32 value to an already existing i64 value using add_i32(). In your examples, both 'abs' and 'neg' are operations to be done directly in the pdf_i64_t without any additional i32 value involved, so doesn't make much sense to have a _i32 variant, which in fact I don't understand what they would be doing. > > Finally, I did find a need for pdf_i64_eq() and pdf_i64_neq(). I'd > like to add them to the public specification. I also found a need for > pdf_i64_shl() and pdf_i64_shr(). I don't know if they should be public > or private, so I'd like to error towards private. There is no real need for _eq() and _neq() functions when pdf_i64_cmp() is already in the API. And what's the specific need for _shl() and _shr()? Cheers, -Aleksander
