[PATCH] score: Fix _Objects_Shrink_information()

[Sebastian Huber]

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. 
  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.

>
> 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
>
>
>


-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.