<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 4/17/2013 10:15 AM, Ralf Corsepius
      wrote:<br>
    </div>
    <blockquote cite="mid:516EBC76.1060608@rtems.org" type="cite">
      <pre wrap="">On 04/17/2013 02:53 PM, Sebastian Huber wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 04/17/2013 12:19 PM, Ralf Corsepius wrote:
[...]
</pre>
        <blockquote type="cite">
          <pre wrap="">@@ -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;
</pre>
        </blockquote>
        <pre wrap="">
A long must be able to store a 32-bit integer so there is no need to use
uint32_t here.
</pre>
      </blockquote>
      <pre wrap="">
Such is theory - Realty is different.

The assumptions of long >= 32 bit only applies to POSIX conformant targets.
</pre>
    </blockquote>
    According to Wikipedia, C99 requires long to be >= 32 bits<br>
    <a href="http://en.wikipedia.org/wiki/C_data_types">(http://en.wikipedia.org/wiki/C_data_types</a>)
    which matches<br>
    the definition of LONG_MIN/LONG_MAX in limits.h per this<br>
    admittedly draft from 2005 TC3 version of the standard <br>
    <br>
    <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf</a><br>
    <br>
    It appears this is the last draft before final vote.<br>
    <blockquote cite="mid:516EBC76.1060608@rtems.org" type="cite">
      <pre wrap="">
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.
</pre>
    </blockquote>
    I tried the h8300 multilibs and got sizeof(long)==4.  I recall cases
    where there <br>
    were warnings when int overflowed when << by more than  16
    bits.  But that's<br>
    reasonable. int can be 16 bits and we have third party code that
    primarily <br>
    supports 32-bit environments. That leaves this question:<br>
    <br>
        Which target and multilib has long < 32-bits? <br>
    <br>
    I can only think of one case -- avr when -mint8 is specified and the
    gcc manual<br>
    says this:<br>
    <br>
    `-mint8'<br>
         Assume int to be 8 bit integer.  This affects the sizes of all<br>
         types: A char will be 1 byte, an int will be 1 byte, an long
    will<br>
         be 2 bytes and long long will be 4 bytes.  Please note that
    this<br>
         option does not comply to the C standards, but it will provide
    you<br>
         with smaller code size.<br>
    <br>
    I thought we assumed C99 and although I can't find the C89 standard<br>
    to check if this changed. The gcc manual doesn't mention anything on
    this.<br>
    <br>
    If we have a specific case in mind, it needs to be commented on by
    GCC C language<br>
    lawyers. It looks to be a violation of the standard to me.<br>
    <br>
    If int8 on the avr is the issue, then I think that multilib needs to
    be excluded <br>
    because we assume standard C.<br>
    <blockquote cite="mid:516EBC76.1060608@rtems.org" type="cite">
      <pre wrap="">

Ralf




_______________________________________________
rtems-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a>
<a class="moz-txt-link-freetext" href="http://www.rtems.org/mailman/listinfo/rtems-devel">http://www.rtems.org/mailman/listinfo/rtems-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Joel Sherrill, Ph.D.             Director of Research & Development 
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a>        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805 
Support Available                (256) 722-9985 </pre>
  </body>
</html>