From owner-cvs-all Tue Feb 5 16:41:45 2002 Delivered-To: cvs-all@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 654) id DF7F337B41A; Tue, 5 Feb 2002 16:41:42 -0800 (PST) Date: Tue, 5 Feb 2002 16:41:42 -0800 From: Mike Smith To: "Andrey A. Chernov" Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c Message-ID: <20020205164142.A88266@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > dictionary building. In my opinion, Andreys example is a good > > example of very poor pseudo-random number usage. he simply needs > > to call srandom() in a better place. > > Imagine not Andrey but some abstract person writting application for PAM. > How do you plan to tell every such person to NOT use random() in the way I > demonstrate? Most people wouldn't expect state like that to be preserved across calls into an arbitrary API. If you really care about this, you're going to have to come up with a completely separate set of APIs for library-internal usage. There's less in the way of functions with static data storage nowadays (since threaded programs have made it clear how stupid this is); you're just discovering over again that this isn't a sustainable model. Realistically, if you care about deterministic behaviour from a RNG, you want to own the state for the RNG yourself, not pray that nobody else is going to use it when you're not looking. Any other expectation is just bad design. = Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message