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