Date: Mon, 21 Jan 2002 09:21:02 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Mark Murray <mark@grondar.za> Cc: Terry Lambert <tlambert2@mindspring.com>, current@FreeBSD.ORG Subject: Re: Step1, pam_unix srandomdev fix for review Message-ID: <20020121092102.C72285@gsmx07.alcatel.com.au> In-Reply-To: <200201202151.g0KLp7t34081@grimreaper.grondar.org>; from mark@grondar.za on Sun, Jan 20, 2002 at 09:51:07PM %2B0000 References: <3C4B3775.1AFA318@mindspring.com> <tlambert2@mindspring.com> <200201202151.g0KLp7t34081@grimreaper.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-Jan-20 21:51:07 +0000, Mark Murray <mark@grondar.za> wrote: >> > Second step is effectively damages srandom(3) RNG state. >> >> Since the library is a totally encapsulated usage, it makes sense >> for it to save and restore state aroun its use of the functions, >> which would effectively allow concurrent use of the generator >> with other code that uses it. >> >> Other code that cares about the state should do the same. > >True but not trivial. I'd be happy to commit working patches :-) The simplest solution would appear to be to add srandom_r() and random_r() functions - both of which take an initstate() buffer. It should be possible using setstate() but there doesn't appear to be a documented sequence to restore the internal random state to "uninitialised". Is there any good reason why random_r(), srandom_r(), srandomdev_r() should not exist? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020121092102.C72285>