Re: [avr-libc-dev] rand(3) in avr-libc

[Joerg Wunsch]

As Theodore A. Roth wrote:

> :) Also, RAND_MAX was set to 0x7fffffff, but the return type is only int
> :) (which is unfortunately mandated by the ISO C standard).  This doesn't
> :) fit very well...

> Your patch is still using longs inside the function and then
> returning an int. Aren't longs 32 bit and ints 16 bit for avr?

Yep.

> What's the effect of this?

The internal computation is done using 32-bit numbers.  AFAICT, this
needs to stay, since the algorithm is written with 32-bit numbers in
mind, i. e. if you reduce it to 16 bits, it won't yield the good
random numbers it's said to get you currently.

> Should we return long in this case?

Nope, the ISO C standard forbids this.  rand() needs to return int.

Unix systems usually also ship a random() function which returns a
long.  We could write a second file for this.  (Unfortunately, porting
the complete random.c yielded a file that generated 2 KB of code...
So i'd rather use what we've got for rand.c, and just turn it into
something that uses longs for the return type and for seeding.)

> :) Opinions anyone?  Should i keep rand_r() support?
> 
> rand_r() might still be needed for avr. Even without threads, you may
> still need to use re-entrant functions in certain cases (for example,
> interrupts, but that's a poor example ;-)

OK, then we can keep it.  It only costs a few bytes.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/