From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.bugs Subject: bug#32605: [w64] (random) never returns negative Date: Sat, 14 Aug 2021 09:31:06 +0100 Message-ID: <86mtpksa0l.fsf@gmail.com> References: <855zzpf86u.fsf@gmail.com> <87zhx1ktp0.fsf@gmx.net> <87zhwwhp9i.fsf@gmail.com> <87mtpmls3p.fsf_-_@gnus.org> <83o8a2dbjo.fsf@gnu.org> <86bl62s8qm.fsf@gmail.com> <83czqhdfhm.fsf@gnu.org> <861r6xoxqa.fsf@gmail.com> <83sfzcbmfm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27380"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt) To: 32605@debbugs.gnu.org Cancel-Lock: sha1:agTNNJIL25tRJpafpya5+yoSNgw= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 14 10:32:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mEp5O-0006xK-SS for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 10:32:10 +0200 Original-Received: from localhost ([::1]:60718 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEp5N-000740-Cl for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 04:32:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53108) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEp5G-00073d-CT for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 04:32:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60202) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mEp5G-0000YD-4z for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 04:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mEp5F-0005e9-Vl for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 04:32:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <855zzpf86u.fsf@gmail.com> Resent-From: Andy Moreton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 08:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32605 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.162892988321651 (code B ref -1); Sat, 14 Aug 2021 08:32:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 14 Aug 2021 08:31:23 +0000 Original-Received: from localhost ([127.0.0.1]:43515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEp4d-0005d9-BT for submit@debbugs.gnu.org; Sat, 14 Aug 2021 04:31:23 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:48020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEp4a-0005cz-20 for submit@debbugs.gnu.org; Sat, 14 Aug 2021 04:31:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53012) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEp4Y-0006t5-Oz for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 04:31:19 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:35836) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEp4W-0008Rv-Jl for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 04:31:18 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mEp4T-0005qX-QQ for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 10:31:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:211811 Archived-At: On Sat 14 Aug 2021, Eli Zaretskii wrote: >> From: Andy Moreton >> Date: Fri, 13 Aug 2021 22:12:29 +0100 >> >> You elided the detail of my previous message: > > Because I had nothing useful to say in response. If someone wants to > work on a better emulation of 'random' for w64, that's fine; I don't > consider myself an expert in this area, and therefore not sure I even > understand the significance of providing 31 bits of randomness from a > functions such as 'random', which AFAIR is not the standard of RNGs. > My goal was to make the current implementation better with relatively > simple and straightforward changes. Calling rand_as183 one more time > is IMHO not a good solution; but again, I'm not an expert. Please look at get_random() in sysdep.c: it constructs wider random numbers by concatenating random bits from calling random() in a loop, and expects that the result of each call in that loop returns RAND_BITS (defined in sysdep.c as 31 on this platform). The random() replacement in w32.c does not meet this contract, as it only provides 30 bits, causing get_random() to produce a concatenated result containing bits with fixed, non-random values. >> > What about the variant below, does it produce better results? >> > >> > int val = ((rand_as183 () << 15) | rand_as183 ()); >> > #ifdef __x86_64__ >> > return 2 * val - 0x7FFFFFFF; >> > #else >> > return val; >> > #endif >> >> Why is this any better ? On 32bit builds it does not return 31 random >> bits (only a 30bit value) and on 64bit builds the lowest bit is not >> random. > > I hoped it will be better because it produced negative values as well, > not only positive values, without any performance penalty. For a > problem that was left unsolved for 3 years it sounds good enough to > me. There doesn't seem to be any point in making changes if they disguise a bug rather than fixing it. Your proposal just changes which bits in the the result are non-random. > So my proposal is to install the above until someone comes up with a > better solution. But if that's unacceptable, let alone if my > participation in this discussion is an annoyance, like it seems to be, > I'll readily bow out of it. As far as I can see the way to fix this is one of: a) Fix random() in w32.c to return a 31 bit random number. b) Modify the logic in sysdep.c that defines RAND_BITS to set it to 30 on this platform, so get_random() produces working results. The get_random() loop would then need one call to random on 32bit builds (FIXNUM_BITS is 30), and three on 64bit builds (FIXNUM_BITS is 62). I'm not an expert on random numbers either, and your efforts are not an annoyance, but I am puzzled why you so strongly prize performance over correctness in this instance. AndyM