[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug: Getting dice from random.org for the second time

From: Christian Anthon
Subject: Re: Bug: Getting dice from random.org for the second time
Date: Thu, 13 Aug 2020 09:40:22 +0200

No this has probably always been the way it worked, but depending on the number of random numbers you ask for and on the implementation of libcurl you will get either one or more callbacks to RandomOrgCallBack. This should do the trick:

<     unsigned int iNumRead = 0;
>     unsigned int iNumRead = pvRandomData->nNumRolls;;
<     pvRandomData->nNumRolls += iNumRead;
>     pvRandomData->nNumRolls = iNumRead;


On Wed, Aug 12, 2020 at 10:39 PM Philippe Michel <philippe.michel7@free.fr> wrote:
On Wed, Aug 12, 2020 at 05:09:44PM +0200, Christian Anthon wrote:

> Definitely a bug of some kind. The dice generator either runs out
> prematurely or decides that 0 is a valid rolid. I added a bit of debug code
> and it ended around 450 rolls each time and decided to return 0...

I confess ; I had been lazy and changed the batch size to 50 to check
faster... With it back to 500 I see the same error than Peter.

After rebuilding with RANDOMORG_DEBUG set to 1, I get a popup with
something like:

Random rolls received: 233155434624322265542633155145126431145541114223451435642
15443664451264523662522552136111142655314662256113354626334415Random rolls recei
ved: 422134663136156533445661522555423255452655414616465514653664534156643361522

GNUbg rolls 4, You rolls 2.

4-2, not 2-3. It looks like RandomOrgCallBack() is called twice and the
second group of digits clobbers the first one instead of being appended
to it.

FWIW, I was a bit surprised how fast it went through "500" dice.
Possibly, for me it failed at less than 450, either the lentgh of the
second string or that of the longer of them, between 200 and 300.

Anyway, the issue is indeed not getting dice for the second time (it
doesn't even get there) but dropping some of those we got initially and
unexpectedly running out of them.

It's strange this was not noticed earlier. Maybe random.org changed
something in the way it sends numbers, or libcurl in the way it pulls
them, in smaller sets than it used to.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]