[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-gcc-list] Re: [avr-libc-dev] rand(3) in avr-libc
From: |
Joerg Wunsch |
Subject: |
[avr-gcc-list] Re: [avr-libc-dev] rand(3) in avr-libc |
Date: |
Tue, 10 Sep 2002 12:44:44 +0200 |
User-agent: |
Mutt/1.2.5i |
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/
avr-gcc-list at http://avr1.org
- [avr-gcc-list] Re: [avr-libc-dev] rand(3) in avr-libc,
Joerg Wunsch <=