Re: [pdf-devel] Base Types API

[Jeffrey Walton]

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 <address@hidden> 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
>