[PATCH] score: Fix _Objects_Shrink_information()

[Ralf Corsepius]

On 01/04/2013 10:48 AM, Sebastian Huber wrote:
> On 01/04/2013 10:30 AM, Ralf Corsepius wrote:
>> On 01/03/2013 05:08 PM, Sebastian Huber wrote:
>>> The chain iteration was wrong.  The chain tail is not an object.
>>> ---
>>>   cpukit/score/src/objectshrinkinformation.c |   36 
>>> ++++++++++++---------------
>>>   1 files changed, 16 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/cpukit/score/src/objectshrinkinformation.c
>>> b/cpukit/score/src/objectshrinkinformation.c
>>> index de32f24..466a85d 100644
>>> --- a/cpukit/score/src/objectshrinkinformation.c
>>> +++ b/cpukit/score/src/objectshrinkinformation.c
>>> @@ -34,12 +34,9 @@ void _Objects_Shrink_information(
>>>     Objects_Information *information
>>>   )
>>>   {
>>> -  Objects_Control  *the_object;
>>> -  Objects_Control  *extract_me;
>>>     uint32_t          block_count;
>>>     uint32_t          block;
>>>     uint32_t          index_base;
>>> -  uint32_t          index;
>>>
>>>     /*
>>>      * Search the list to find block or chunk with all objects 
>>> inactive.
>>> @@ -52,25 +49,24 @@ void _Objects_Shrink_information(
>>>     for ( block = 0; block < block_count; block++ ) {
>>>       if ( information->inactive_per_block[ block ] ==
>>>            information->allocation_size ) {
>>> +      Chain_Node       *node = _Chain_First( &information->Inactive );
>>> +      const Chain_Node *tail = _Chain_Immutable_tail( 
>>> &information->Inactive );
>>> +      uint32_t          index_end = index_base + 
>>> information->allocation_size;
>>
>> FWIW: I believe all these "index*" vars, should be size_t (or may be 
>> off_t) and
>> not be uint32_t.
>
> Ok, but this integer type inconsistency has nothing to do with the 
> chain iteration fix.
>
> The information->allocation_size, information->maximum, and 
> information->inactive are of type Objects_Maximum which is uint8_t or 
> uint16_t.
IMO, this is a bug. All sizes should be size_t.

> The first problem is that information->inactive_per_block is of type 
> uint32_t which should be Objects_Maximum to save space since 
> information->inactive is the sum of all information->inactive_per_block.
>
> For calculation with Objects_Maximum type integers we should use not 
> use size_t since on 32-bit architectures uint16_t is promoted to int.  
> I think uint_fast16_t is the right type.
I am not sure, but I am having doubts on this.

>
>>
>> Dunno of-head if this can easily be changed or if this just one of 
>> links in the
>> long chains of uint32_t vs. size_t vs. off_t issues RTEMS is known to 
>> suffer from.
>>
>> Ralf
>>
>>
>>
>
>