Potential INT type problems in rare cases with old compilers in RNG
From a quick Internet search, it can not be guaranteed that uint64_t and uint32_t are defined. I'm hesitant to commit the following code (and the according 32 bit case) to the RNG:
#if (!defined UINT64_MAX) && (!defined uint64_t) && (!defined HAS_UINT64_T) //this is from <stdint.h>: #if __WORDSIZE == 64 typedef unsigned long int uint64_t; #else extension //prevent warnings typedef unsigned long long int uint64_t; #endif #endif
because a) I don't know if ""!defined uint64_t"" is adequate or of any better way to check if the type is really ""physically"" available and b) because as a case shows the types can actually be there while UINT64_MAX is not (don't know about HAVE_UINT64_T) and so we would have two typedefs for the same thing. If I understood correctly, this link [1] suggests that defining __STDC_LIMIT_MACROS for the compilers will make them get the definitions from stdint.h.
So, if I'm not mistaken we could either:
- make certain the compiler defines UINT64_MAX and/or HAS_UINT64_T if the types are there with a flag and run something like the code above
- check in a smarter way if uint64_t (and uint32_t) exist and if not do the typedef.
Then, as long as something is there the RNG is fine with it, because knowing the bits it works with masks can be used throughout. (As Mathias showed in a previous commit, numeric_limits should be used for dynamic types.)
As it is, I think in rare cases it may not compile.
The RNG header may also not be the best place to put something like this in?
[1] https://lists.gnu.org/archive/html/autoconf/2011-12/msg00008.html