I appreciate your response, Damien.

I did do the bare minimum of correctness testing and it was the post right
after Guenther was congratulated on proving incorrectness:

https://marc.info/?l=openbsd-tech&m=165259528425835&w=2

The post includes software to reproduce the results.



I wrote a highly dynamically allocated program to test at intervals of
intervals to show at various stages to show the degree that the output
remains random

This is an example of some output:

testing arc4random_uniform(5) and arc4random_uniform_small_unlocked(5):

                     256X         2048X        16384X       131072X
 1048576X

 ....................................................................
   0 original        246          2053         16400        131115
1048306
         mine        263          2042         16312        131258
1046989

   1 original        234          2013         16337        130894
1047810
         mine        249          2022         16304        131161
1049511

   2 original        236          2061         16367        130802
1047430
         mine        257          2117         16597        130718
1046375

   3 original        284          2089         16444        131092
1050332
         mine        266          2058         16379        131190
1049877

   4 original        280          2024         16372        131457
1049002
         mine        245          2001         16328        131033
1050128



max-min values:

     original         50            76           107           655
 2902
         mine         21           116           293           540
 3753


The program is set up to test values 2 through 50. This will create 224KiB
of output.
I suspected that you'd prefer that I didn't attach it.

Some progress output has been relegated to stderr so that you can easily
pipe it to a file.

I added some getrlimit an setrlimit functions to maximize memory limits if
necessary
In the case that I created for you, this will not be needed.

It uses 1276K RAM in the current configuration.


> Just to bring this back to where we came in: even putting thread-safety
> aside (which you absolutely can't): it doesn't matter how much faster
> it is, your replacement function isn't useful until you do the work to
> demonstrate correctness.
>
> You have done literally zero so far, not even the bare minimum of
> testing the output. As a result your first version was demonstrated to
> be completely broken by literally the most basic of possible tests, a
> mere 10 lines of code.
>
> That you left this to others to do tells me that you fundamentally don't
> understand the environment in which you're trying to operate, and that
> you don't respect the time of the people you're trying to convince.
>
> Please stop wasting our time.
>
> -d

-- 
-Luke

Attachment: arc4random_uniform_small.c
Description: Binary data

Reply via email to