On 2021/08/01 18:01, Paul de Weerd wrote:
> This has now been committed, but it got me to wonder - why is there no
> 64-bit variant of arc4random_uniform(3)? Of course not to solve this
> one issue, but I've wanted to use the wider version in the past and
> then resorted to implementing the
This has now been committed, but it got me to wonder - why is there no
64-bit variant of arc4random_uniform(3)? Of course not to solve this
one issue, but I've wanted to use the wider version in the past and
then resorted to implementing the 64-bit variant in my own program.
Below diff (tested
On Thu, Jul 29, 2021 at 07:35:24PM +0200, Theo Buehler wrote:
> On Thu, Jul 29, 2021 at 11:23:30AM -0600, Todd C. Miller wrote:
> > On Thu, 29 Jul 2021 07:11:26 -0600, "Theo de Raadt" wrote:
> >
> > > I'm not sure about the tradeoff in this approach.
> > >
> > > Won't the lack of precision in
Looks great.
Theo Buehler wrote:
> On Thu, Jul 29, 2021 at 11:23:30AM -0600, Todd C. Miller wrote:
> > On Thu, 29 Jul 2021 07:11:26 -0600, "Theo de Raadt" wrote:
> >
> > > I'm not sure about the tradeoff in this approach.
> > >
> > > Won't the lack of precision in double eventually lead to
On Thu, 29 Jul 2021 19:35:24 +0200, Theo Buehler wrote:
> I think we should keep uintx as an uint32_t since that's what the
> arc4random() family expects. I'd argue that the check is wrong in that
> it should be done before assigning the double to an uint32_t.
>
> I'd suggest this diff:
Event
On Thu, Jul 29, 2021 at 11:23:30AM -0600, Todd C. Miller wrote:
> On Thu, 29 Jul 2021 07:11:26 -0600, "Theo de Raadt" wrote:
>
> > I'm not sure about the tradeoff in this approach.
> >
> > Won't the lack of precision in double eventually lead to non-uniformity?
> >
> > The way jot is written, I
On Thu, 29 Jul 2021 07:11:26 -0600, "Theo de Raadt" wrote:
> I'm not sure about the tradeoff in this approach.
>
> Won't the lack of precision in double eventually lead to non-uniformity?
>
> The way jot is written, I expect higher ranges to have lots of
> non-uniformity unless a substantial
I'm not sure about the tradeoff in this approach.
Won't the lack of precision in double eventually lead to non-uniformity?
The way jot is written, I expect higher ranges to have lots of
non-uniformity unless a substantial rewrite is undertaken, but I am
worry your approach creates non-uniformity
Hello,
jot(1) appears to give unsatisfying randomness when used
with larger numbers (and -r):
# (before diff)
% jot -r 10 10 99
1294196288
1351335130
1105868309
1082237294
1078729542
1009152305
1108537886
1362127442
1071708731
1402965187
That is because in jot.c we see:
249
