n must be signed. It can be int or ssize_t, but it needs to be signed. Otherwise the if (n < 0) condition can literally never happen.

We need to make sure the min & max values weren't the same.

You're already checking this on line 126.

Oh snap. Not. Enough. Coffee! Oh wait, I'm drinking decaf for some reason today. :/

What is the principal difference of this move from casting some garbage into integer? Could someone point to a theory behind this?

What do you mean? How else would you do it?

Yeah, that was actually my question :) Maybe I'm too fixed on LCG, so just making a stab on finding some system. In a LCG one would have a seed and a kind of formula. Here, we read some sequence of bits which are then inclined to be an integer.

Probably right, at the end those bits are glued together. At the end, the integer is in the exact range of how much bits was requested. But just wondering, no further shuffling, endianness difference, etc., just taking them as is? Are there some tests on the quality of the outcome? That's basically what I was asking.

@weltling There is no need. If the input to the algorithm is a sequence of independent, uniformly-distributed random bytes then the its output is guaranteed to be independent, uniformly-distributed over the requested range and have the same "kind" of randomness as the input. In this case, since we are using trusted sources of crypto-secure pseudo-random bytes, the output is a crypto-secure pseudo-random integer.

Try thinking of it this way. Say you need random numbers in the range 0 to 13 and all you have as a source of randomness is a friend with a 20-sided die. The only way (that I know) to get the numbers you need without bias or skewing the distribution is to ask your friend to keep rolling the die until it gives a number in the desired range.

Now, say you need numbers in the range 0 to 8. You can map two disjoint subsets of the die's 0 to 19 range to the desired range and this improves the algorithm's efficiency.

I believe this is exactly analogous to how this algorithm is supposed to work. (I am making no comment about the correctness of the implementation.)

It's an old algorithm we can trust.

@weltling There's no need for any extra work. If an integer occupies 64 bits of memory, and we use a random source to set every one of those bits, the result is a random integer with the same quality as the random source.

Endianness does not matter since every byte is independently random. If the bytes are ordered AB they are equally random to being ordered BA.

There are tools that can test the quality of the random output, but you'll literally be testing the underlying source. We're putting our faith in the Linux/Windows/BSD APIs here. If it turns out that these sources are in fact low quality, then civilisation itself will collapse :)

@tom--

I believe this is exactly analogous to how this algorithm is supposed to work.

Indeed. Find the ceiling under RAND_MAX where upper_bound % ceiling == 0, and discard all values greater than that ceiling.

@lt the world is concurrent enough to not to break because of whichever virtual RNG :) But ok, so the presumption of innocence is applied to the OS randomness sources.

@tom-- yeah, maybe also an improvement could be to ask the friend to throw more than one die at once. Possibly it could reduce the whole circles count. However not sure how reliable it would be with this method (i mean how many uniform random data one can get at once), for LCG i can say it could be done with something like AVX/SSE vectorization capabilities. Here it's probably only to be spotted empirically.

Thanks for the answers, guys.