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

[Joel Sherrill]

Ignoring everything except Ralf's initial question, I did this
analysis.

These are the "return information" fields available for use in the TCB
we have to choose from:

  uint32_t              count;
  void                 *return_argument;
  void                 *return_argument_1;
  uint32_t              option;
  uint32_t              return_code;

coremsgseize.c does this when a thread blocks:

  executing->Wait.return_argument    = buffer;
  executing->Wait.return_argument_1  = (void *)size;

size is passed in as a size_t so it is certainly bad to put it
in return_argument_1.  We  should have used option or count
and not forced it into return_argument_1. 

Which is better to use in your opinion Ralf?  We need to pick
something instead of return_argument_1 for size and use it
consistently. return_argument_1 should only hold pointers.

Do we need to change count or option to another name and
use size_t instead of uint32_t? 

As  a future improvement, I can see minimizing the fields in
the Wait_Information structure by having 2-3 instances of
a multitype union (e.g. a union with a void *, uint32_t, and
a size_t).

--joel


Till Straumann wrote:
> Ralf Corsepius wrote:
>> On Tue, 2007-02-06 at 18:10 -0600, Joel Sherrill wrote:
>>  
>>> Till Straumann wrote:
>>>    
>>>> Joel Sherrill wrote:
>>>>      
>>>>> Till Straumann wrote:
>>>>>        
>>>>>> Joel Sherrill wrote:
>>>>>>          
>>>>>>> I think I have fixed all the message queue compilation error 
>>>>>>> issues in 4.7 and 4.8.  I
>>>>>>> can compile for sparc/leon2 now anyway.
>>>>>>>
>>>>>>>               
>>>>>> Shouldn't we fix that ugly    void*  <-> uint32_t cast (by means
>>>>>> of a union) ?
>>>>>>           
>>
>> You didn't get the point: I am having strong doubts this to be necessary
>> and correct. 
>>   
> I do get the point but I believe you are wrong. I provided an
> analysis of the issue - please reply to that or come up with
> some sort of proof for your suspicion.
>
> T.
>> I am saying we have a bug somewhere.
>>   
>
>> Ralf
>>
>>
>>   
>