[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Can't build CVS rtems-4-7-branch



Till Straumann wrote:
> Joel Sherrill wrote:
>> Joel pushes reset and goes back to the start.
>>
>> Ralf Corsepius wrote:
>>> Have a look at my patch:
>>>
>>> Here is one:
>>> --- cpukit/score/src/coremsgseize.c     6 Feb 2007 03:50:47 
>>> -0000       1.11
>>> +++ cpukit/score/src/coremsgseize.c     6 Feb 2007 17:16:25 -0000
>>> @@ -107,7 +107,7 @@
>>>       */
>>>  
>>>      the_message->priority  = the_thread->Wait.count;
>>> -    the_message->Contents.size = (uint32_t  
>>> )the_thread->Wait.return_argument_1;
>>> +    the_message->Contents.size = the_thread->Wait.return_size;
>>>      _CORE_message_queue_Copy_buffer(
>>>        the_thread->Wait.return_argument,
>>>        the_message->Contents.buffer,
>>> return_argument_1 is a void*, Contents.size is uint32_t => Illegal 
>>> cast.
>>>
>>>   
>> This is the unblocking path from a message queue submit that 
>> blocked.  The blocking
>> code is the bottom of coremsgsubmit.c:
>>
>>    executing->Wait.id                 = id;
>>    executing->Wait.return_argument    = buffer;
>>    executing->Wait.return_argument_1  = (void *)size;
>>
>> So the above is definitely casting a size_t (not size_t *) into a 
>> void *.
>> which requires the code Ralf has above to "undo it".  Rather than adding
>> return_size, can we switch to using count for message size and use 
>> option
>> from the Wait information for the message priority?
>> I still believe long term, it would be better to have the various 
>> return_argument
>> fields be unions so the space is more effectively used while also 
>> properly typed.
>>
>> But this case clearly forced an integer through a (void *) return 
>> argument field.
> I came to the same conclusion but besides intermediately storing a
> size_t in a variable declared as a pointer (which is bad, I agree) I
> can't see a bug.
>
I only see type abuse but it appears to be the same on the input and output
side of the code so is consistent. :)

It should go through the remaining uint32_t field in the Wait information.
> T.
>>> Ralf
>>>
>>>
>>>   
>>
>