Re: [pdf-devel] Base Types API

[Aleksander Morgado]

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