Il 24/10/2012 16:41, Kevin Wolf ha scritto:
>> +struct HBitmapIter {
>> + const HBitmap *hb;
>> +
>> + /* Copied from hb for access in the inline functions (hb is opaque). */
>> + int granularity;
>> +
>> + /* Entry offset into the last-level array of longs. */
>> + size_t pos;
>
> Other places, for example HBitmap.size/count and the local pos variable
> in hbitmap_iter_skip_words(), use uint64_t. Why is size_t here enough?
size_t is enough if it is a word position. uint64_t is necessary if it
is a bit position. This line of hbitmap_iter_next explains it well:
item = ((uint64_t)hbi->pos << BITS_PER_LEVEL) + ffsl(cur) - 1;
Here the word position hbi->pos is converted to a bit position, so we
need to convert size_t to uint64_t.
In fact, hbitmap_iter_skip_words could indeed use a size_t. It uses
uint64_t because the line above used to be in hbitmap_iter_skip_words,
and used pos instead of hbi->pos. With that code, using uint64_t saved
a cast.
Paolo
>
>> +
>> + /* The currently-active path in the tree. Each item of cur[i] stores
>> + * the bits (i.e. the subtrees) yet to be processed under that node.
>> + */
>> + unsigned long cur[HBITMAP_LEVELS];
>> +};
>
> Kevin
>
