Background

The crux of the random number issue is as thus:

• rand() returns int
• sizeof(int) on AVR is 2 (i.e. int is 16 bits wide)
• avr-libc introduced random() to provide an equivalent to rand() that returns a 32-bit value instead of a 16-bit value
• Because random() originates from avr-libc rather than Arduino, a lot of devices with Arduino support don't provide many of the extra features provided by avr-libc, including random()
• This library was originally written for an AVR target, leading to a dependency on random() (which at the time was believed by the author to originate from Arduino rather than avr-libc) which unfortunately causes problems with other targets for the aforementioned reasons.

Up until now the solution has been to conditionally disable random number generation depending on which processor is being used.

Recently (see #73 & #74) this was changed to disable random number support for all non-AVR processors in the hopes that non-AVR processors that don't support random() are significantly more plentiful than non-AVR processors that do support random().

Looking forward, it would be good to provide random number support for other non-AVR targets. The most obvious way would be to use rand(), but this should be considered carefully before implementation in case there's another platform with a 16-bit int floating around out there. I.e. at minimum a solution would have to either reject a target with a non-32-bit int or adapt to accomodate it, either by not providing random number generation functions or by generating a function that calls rand() as many times as required to fill the requested number of bits.

Additionally, it would be good to provide a way of interfacing with random number generators that follow the precedent set by the C++ standard library's <random> header, and perhaps a way to accept user-provided function-only PRNGs via detection of the return type.

(As ever, this would be a lot simpler if C++ standard library support were provided for AVR targets. At the very least the <type_traits> header would be invaluable.)