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

[Rempel, Cynthia]

Which architectures are affected?
Thanks!
________________________________________
From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Sebastian Huber [sebastian.huber at embedded-brains.de]
Sent: Wednesday, April 17, 2013 11:27 AM
To: rtems-devel at rtems.org
Subject: Re: [rtems commit] Use uint32_t instead of long. Use unsigned defines ( Prevent overflows on 16bit targets)

On 17/04/13 17:15, 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.

This theory is defined in the C standard.

>
> The assumptions of long >= 32 bit only applies to POSIX conformant
> targets.
>
> 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 doubt that is a good idea to use RTEMS in such a non-standard
environment.  It is all right to fix the (32 * 1024) expression, but
this unsigned long to uint32_t change is nonsense.

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

_______________________________________________
rtems-devel mailing list
rtems-devel at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel