[rtems commit] Use uint32_t instead of long. Use unsigned defines ( Prevent overflows on 16bit targets)

[Ralf Corsepius]

On 04/17/2013 07:46 PM, Joel Sherrill wrote:
> On 4/17/2013 10:15 AM, Ralf Corsepius wrote:
>> On 04/17/2013 02:53 PM, Sebastian Huber wrote:
>>> On 04/17/2013 12:19 PM, Ralf Corsepius wrote:
>>> [...]
>>>> @@ -147,8 +147,8 @@ static uint32_t simple_random(uint32_t v)
>>>>
>>>>    static unsigned get_bucket_with_random(unsigned count, long random)
>>>>    {
>>>> -  long unsigned unit = (1U << 31) / count;
>>>> -  long unsigned bucket = (long unsigned) random / unit;
>>>> +  uint32_t unit = ((uint32_t) 1U << 31) / count;
>>>> +  uint32_t bucket = (uint32_t) random / unit;
>>>>
>>>>      if (bucket != count) {
>>>>        return bucket;
>>> A long must be able to store a 32-bit integer so there is no need to use
>>> uint32_t here.
>> Such is theory - Realty is different.
>>
>> The assumptions of long >= 32 bit only applies to POSIX conformant targets.
> According to Wikipedia, C99 requires long to be >= 32 bits
> (http://en.wikipedia.org/wiki/C_data_types 
> <http://en.wikipedia.org/wiki/C_data_types>) which matches
> the definition of LONG_MIN/LONG_MAX in limits.h per this
> admittedly draft from 2005 TC3 version of the standard
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
>
> It appears this is the last draft before final vote.
>> RTEMS however supports targets, which are not strictly POSIX compliant,
>> where longs are 16bit => The code above fails to compile the code above
>> when using longs.
> I tried the h8300 multilibs and got sizeof(long)==4.  I recall cases 
> where there
> were warnings when int overflowed when << by more than  16 bits.  But 
> that's
> reasonable. int can be 16 bits and we have third party code that 
> primarily
> supports 32-bit environments. That leaves this question:
>
>     Which target and multilib has long < 32-bits?
You've got me, the issue isn't long, it's int.

The code in question fails to build for the h8300/sx due to implicit 
typecasts on 16bit ints.

Ralf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130418/f6fffd44/attachment-0001.html>