Hi Aleksander, >> 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. OK. I'll begin on test cases.
>> If the functions with asterisks are part of the official API, should >> all functions have a <fn>_i32 variant for consistency? ... > Not really OK. Good. > And what's the specific need for _shl() and _shr()? Division requires shifting. Jeff On Thu, Feb 18, 2010 at 5:02 AM, Aleksander Morgado <[email protected]> wrote: > 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 >
