So this is the final verison of the patch solving the following
problems:
>The program is broken in multiple ways: return value clamping, casting
>from double to uint32_t, wrong error checking for putchar, lack of
>warnings when compiling.
Now the program is more pedantic and complicated, but at
t...@theobuehler.org wrote:
>I have no strong opinion. I'm fine with either approach. It's such a
>silly program...
>
>As an aside, random -e has been completely broken (it's non-uniform)
>since forever. To fix -e, we should clamp denom to an integer between
>1 and 256, otherwise the truncation of
>On Wed, Aug 03, 2022 at 08:26:20AM -0600, Theo de Raadt wrote:
>> luci...@bronze.ctrl-c.club wrote:
>>
>> > Another way to solve this problem would be to trim the numbers with
>> > something like this: if (denom > UINT32_MAX) denom = UINT32_MAX.
>>
>> And then document that the program returns i
for the full floating
>point range is more important than what arc4random_uniform() is trying
>to do. But maybe a uniform version of the double code can grow out of
>using the drand48.c code?
Theo, I'm not sure I understand your reasoning. Are you trying to say
that we should see if it's possible to create a drand48_uniform?
-lucic71
ferrror tests the internal flags of the stream.
-lucic71
Index: random.c
===
RCS file: /cvs/src/games/random/random.c,v
retrieving revision 1.20
diff -u -p -r1.20 random.c
--- random.c7 Mar 2016 12:07:56 - 1.20
