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

[Joel Sherrill]

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?

I can only think of one case -- avr when -mint8 is specified and the gcc 
manual
says this:

`-mint8'
      Assume int to be 8 bit integer.  This affects the sizes of all
      types: A char will be 1 byte, an int will be 1 byte, an long will
      be 2 bytes and long long will be 4 bytes.  Please note that this
      option does not comply to the C standards, but it will provide you
      with smaller code size.

I thought we assumed C99 and although I can't find the C89 standard
to check if this changed. The gcc manual doesn't mention anything on this.

If we have a specific case in mind, it needs to be commented on by GCC C 
language
lawyers. It looks to be a violation of the standard to me.

If int8 on the avr is the issue, then I think that multilib needs to be 
excluded
because we assume standard C.
>
> Ralf
>
>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

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