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

[Joerg Wunsch]

As Joerg Wunsch wrote:

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

OK, here it goes.

It fixes the remaining problems with using long constants in the
source code (that silently got truncated to 16 bits before), it uses
the newer algorithm by default to produce better randomness, and IMHO
we also need to pass an unsigned long * (as opposed to an unsigned *)
in rand_r() since we'd otherwise truncate the temporary storage which
defeats the entire algorithm.  Even the old algorigthm (that's used if
USE_WEAK_SEEDING is defined) required a `long' for temporary storage.

As for supplying an additional set of functions returning long instead
of the standards-mandated int, there are two options i would see:

1 We copy over the existing rand.c into a random.c, and just replace
  the result type (and the type passed to srandom()) from `int' to
  `long', including of course using RANDOM_MAX == 0x7fffffff for
  limiting the result.  The advantage is that the resulting file will
  still be relatively small (~ 300 bytes of ROM).

2 We port over the full-fledged random.c from BSD.  This would offer a
  more sophisticated pseudo-random number generator that while using
  the same algorithm that's now in the proposed rand.c file, can use a
  lot more of temporary storage for state information (up to 256
  bytes) to increase the period.  To quote the BSD man page:

     With 256 bytes of state information, the period of the random
     number generator is greater than 2**69 which should be
     sufficient for most purposes.

  However, porting this file would make it consume about 2 KB of flash
  ROM when linked into the binary, for the added value of providing a
  PRNG that could even be used for cryptographic purposes provided it
  is getting seeded with a value that is unpredictable enough (which
  is outside the scope of the library implementation, of course).

What would people prefer?  I've added avr-gcc-list to get opinions,
please honor the mail-followup-to header when replying.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/