[interfacekit] Re: BHandler::fToken, int32 or... uint32!??!?

BHandler::fToken was originally declared as an int32; that's why it's an 
int32.

Marcus Overhagen wrote:
> Axel D=F6rfler wrote:
> 
> 
>>"Adi Oanca" <e2joseph@xxxxxxxxxx> wrote:
>>
>>>You guys were talking about BHandler::fToken taking values that reach
>>>4.294.967.295, but it is just an int32! That means that it's value 
>>>range is
>>>form -2.147.483.647 to +2.147.483.648!
>>>
>>>I ask you that, because by looking in TokenSpace sources I'm not 
>>>finding the
>>>location where you initialize fTokenCount with -2.147.483.647 !
>>
>>2 billion, 4 billion, who cares=3D3F ;-))
>>Seriously, I don't know if we have to reserve the range smaller than 
>>zero to express failure codes - if we have to we should stick with 
>>int32, if not, we could just switch to uint32 and nobody would see any 
>>difference (that's the theory :).
> 
> 
> This really doesn't matter. If you have a int32 and continue to 
> atomic=5Fadd(&var, 1)
> this will work for the full range, of cause, the first 2^31 will be positive, 
> and the
> other 2^31 will be negative values. But the wrap around to zero will happen
> after 2^32.
> 
> I don't think tokens need to have any special meaning, they are just a 32 bit
> identifier, no matter if you treat it as signed or unsigned (exept if you 
> want to
> reserve negative values as failure codes, but I don't think they are used in 
> this
> case).
> 
> Marcus
> 
> 
>

Other related posts: