Re: [PATCH v3 1/2] compat: add a mkstemps() compatibility function

[David Aguilar <davvid@gmail.com>]

On Wed, Jun 03, 2009 at 09:29:06PM +0530, Antriksh Pany wrote:
> Oh ok, didn't realize the sixth division was not used. In which case,
> we needn't have the sixth division.
> 
> Also, 62^5 compared to 2^32 still gives a ~ 21% probability of the
> fifth division becoming zero, fairly high perhaps.
> 
> The suggestion to change the code to
>    ((uint64_t) tv.tv_usec) << 16)
> might help here. This would still leave about a 1.4% chance of v
> becoming zero, higher than (being pedantic!) what perfect randomness
> would require. Livable. But (just curious), do we see any loss in
> shifting a few more positions?
> 
> - Antriksh


Just a small note -- our mkstemps was adapted from
libiberty's mkstemps.c (gcc-4.something), so if there is
indeed something to fix here then we should let them know.

I looked in libiberty since I assumed that the code in there
was battle-tested and stable.

I feel okay with it as-is, but that's just me.



> On Tue, Jun 2, 2009 at 6:35 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > Antriksh Pany schrieb:
> >> 2. tv_usec has a decimal value range of 0-999999  (10^6 usec make 1
> >> sec). Which means that tv_usec fits completely in 20 bits (or less).
> >> (tv_usec << 16) yields a number that fits completely in 36 bits (or
> >> less). Max value of this number is 999999 * 2^16, or for convenience,
> >> about M = 10^6 * 2^16. This number (in the range of 0 to M) goes on to
> >> be divided by D=62^6. Also, M > D. Thus, there is about a  D / M * 100
> >> ~ 87 % probability of the division M / D working out to be zero. i.e,
> >> in 87% cases, the last division (v/= num_letters) will cause 'v' to
> >> become 0.
> >
> > But this value (after the 6th division, mind you) is not used. v is used
> > the last time after the 5th division; at this time it still carries enough
> > randomness: 62^5 < 2^32.
> >
> > -- Hannes
> >
> >

-- 
		David