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:
41c41 < unsigned int iNumRead = 0; --- > unsigned int iNumRead = pvRandomData->nNumRolls;; 65c65 < pvRandomData->nNumRolls += iNumRead; --- > pvRandomData->nNumRolls = iNumRead; C On Wed, Aug 12, 2020 at 10:39 PM Philippe Michel <[email protected]> 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 > > 65551565515156631526333351513342233543262155255516114651145513263135353261523241 > > 44546433422653135141444546614251431231636535313213554551424521224135253445614526 > 15443664451264523662522552136111142655314662256113354626334415Random rolls > recei > ved: > 422134663136156533445661522555423255452655414616465514653664534156643361522 > > 45356656635145226423234544324216365235624163135555343115123661115365646244156465 > 442233253323236435332626562332214365152234362532556336422222616236 > > 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. >
