From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117959 invoked by alias); 31 May 2018 03:04:29 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 117795 invoked by uid 89); 31 May 2018 03:04:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=books, hood, lastly, H*Ad:U*libc-help X-HELO: mail-wm0-f41.google.com Received: from mail-wm0-f41.google.com (HELO mail-wm0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 31 May 2018 03:04:08 +0000 Received: by mail-wm0-f41.google.com with SMTP id 18-v6so45621913wml.2 for ; Wed, 30 May 2018 20:03:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=G8INoG5vhQFGYTze21TEKWScrusjYAj88YOVDDYG+Zg=; b=XehceFMwcg4Z+0NvancIbfUC+G9AqORbGqLztluTHnaVsyy5BcFGOe8AAFuPwHISoX N59iSak9NGejVlUmPCqhFWnk8GkSRQXW6Domzo0to6czdNAZ5wZXmN4sfdUU1+vRctXZ l3QBy06UUtJe63TLCQGrjk1qv+1kGz5UG0VL/4C4Hj7+1sCd0+xoG4Ebl1QZjZXzV9f/ 43eLCdyjytgcJUHD5tVaBbo+d039n7qCIdr5vo8pJF9ec0xSP+8ig69QaQ/FZRWrBvsW Pg32TNv9vqiroAzbhZaXigiMp1Q9HphMG8hGsIuErt++l5rHObkfb7x3Dbd2U+Bl/qu6 /ufQ== X-Gm-Message-State: ALKqPwfHYXEJVwPgASoVtgtzbVoAiaaMZj+UfjBiDc8QxOPQBaxV35Tj AJHG8mlxxOOIMy1BX2Vr+4end4Aw/+r2YXNXEYSCit1n X-Google-Smtp-Source: ADUXVKLN4MamLCKWK077xBwHfFGGwiGSu29Jkoy44V8fMkp6dyeJNyiouBFGxP4v2sgVAr5iAVOwoXM5027+E50SkiQ= X-Received: by 2002:a1c:d50a:: with SMTP id m10-v6mr3069685wmg.72.1527735828011; Wed, 30 May 2018 20:03:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:1741:0:0:0:0:0 with HTTP; Wed, 30 May 2018 20:03:47 -0700 (PDT) From: Xinzhen Chen Date: Thu, 31 May 2018 03:04:00 -0000 Message-ID: Subject: What is the reason for multiplying 10 in __srandom_r? To: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-05/txt/msg00033.txt.bz2 Hello, glibc developers :-) I was trying to understand what functions like rand() do under the hood. I compiled glibc 2.27 from source and link the new compiled libc.so.6 to my test C program in the following: #include #include int main(int argc, char const* argv[]) { int randt[32] = {0}; initstate(2, (char*)randt, 128); setstate((char*)randt); printf("%d\n", rand()); return 0; } I used gdb to step into initstate() function and got confused when I stepped into the following line of __srandom_r function: kc = buf->rand_deg; for (i = 1; i < kc; ++i) { /* This does: state[i] = (16807 * state[i - 1]) % 2147483647; but avoids overflowing 31 bits. */ } buf->fptr = &state[buf->rand_sep]; buf->rptr = &state[0]; kc *= 10; while (--kc >= 0) { int32_t discard; (void) __random_r (buf, &discard); } I also read the comment of __srandom_r function which says "Lastly, it cycles the state information a given number of times to get rid of any initial dependencies introduced by the L.C.R.N.G.". My questions are: 1. Why the " given number of times" is "kc * 10" instead of "kc * 8" or "kc * 16" which is more efficient in multiplication? 2. Are there papers or books which dive into glibc random implementation ?(I've read some chapters of , ,but still can not totally understand the implementation of glibc random functions)