From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 4565621DA4 for ; Sat, 20 Apr 2024 14:47:18 +0200 (CEST) Received: from duke.felloff.net ([216.126.196.34]) by 9front; Sat Apr 20 08:46:22 -0400 2024 Message-ID: Date: Sat, 20 Apr 2024 14:46:12 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <24YLTYTO4Q79Z.243QVQUY1V3P5@e55-lap.my.domain> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: content-addressed non-blocking strategy descriptor Subject: Re: [9front] [PATCH] libc: replace lrand's algorithm Reply-To: 9front@9front.org Precedence: bulk > I found (rand()<<16) + rand() in kernel's devsdp, which is > strange considering lrand already has 32 bits of output. I > think this should be considered a bug. The manpage states: Rand returns a uniform pseudo-random number x, 0≤ x <2^15. Lrand returns a uniform long x, 0≤ x <2^31. So lrand() only return a positive number (so really, is 31 bit generator, not 32 bit). Also, rand() returns only 15-bit integer. so doing rand()<<16 results in a bias as it will never set bit 15. The lrand() implementation in the kernel is not complient which i think is a mistake. (BUG!) libc does not provide a function for unsigned 32-bit. having one might be a good start. say, lets define: ulong ulrand(void) in range 0<=ulrand()<2^32 and use that as the basis for all the other functions instead of lrand(). Then as you say, constructs like rand()<<16 | rand() should be revisited. -- cinap