From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_PASS,T_DKIM_INVALID, T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id C6AA620282 for ; Wed, 14 Jun 2017 21:58:33 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C92F8120784; Thu, 15 Jun 2017 06:58:31 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 6A645120739 for ; Thu, 15 Jun 2017 06:58:29 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=EplJIhrKBOTP70oUPbPYfXxGOqg=; b=aZ+qmgbibdrfpzFDG4 U7VYBDM29PVwmMfrrgeEd/hX9/8x9Yi6FKUKR3sRshjOrJx6XFWcEffPuEWGdc2X D4dZCv96ds4zqJPMEqtO2WzI//Sh9nJ0TbDST3dUruzrkjtK2ed5ivuffd9JOQRc XgnSf/H3oT/z+4IpnvfWFdAIk= Received: by filter0555p1mdw1.sendgrid.net with SMTP id filter0555p1mdw1-9866-5941B180-3A 2017-06-14 21:58:24.904977899 +0000 UTC Received: from herokuapp.com (ec2-54-83-117-197.compute-1.amazonaws.com [54.83.117.197]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id LVmSaDRERpqgLO4eBVZJkg for ; Wed, 14 Jun 2017 21:58:24.950 +0000 (UTC) Date: Wed, 14 Jun 2017 21:58:24 +0000 From: eregontp@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 56710 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 13660 X-Redmine-Issue-Author: Eregon X-Redmine-Sender: Eregon X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS7XXdebCTfxKkGGj6Y183WHmkU/Ok8Ex2UFQh LfXqybFwbuxiXi8BN24793sL/pOfWyw8K0kxZup8io8xmDcQGPZBkGWysxyBQB/bJ7dokUbAIGU5IU MX6PsC4uZiBwu/c6krXvs4o+NXnmDBIrpzwsZOBgOvpQ8zeVfyLHBaCbnw== X-ML-Name: ruby-core X-Mail-Count: 81682 Subject: [ruby-core:81682] [Ruby trunk Bug#13660] rb_str_hash_m discards bits from the hash X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #13660 has been updated by Eregon (Benoit Daloze). What is particularly puzzling on that AppVeyor log is both hash values at the Ruby level look the same, and have the same object_id, yet the values are not Fixnum#==. ---------------------------------------- Bug #13660: rb_str_hash_m discards bits from the hash https://bugs.ruby-lang.org/issues/13660#change-65374 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.3.3p222 (2016-11-21 revision 56859) [x64-mingw32] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- I believe rb_str_hash_m might discard some bits from the hash value in some situations. It computes the hash as a st_index_t, which is either a unsigned long or a unsigned long long. But the st_index_t value is converted to a VALUE with: #define ST2FIX(h) LONG2FIX((long)(h)) Note that for instance on x64-mingw32, SIZEOF_LONG is 4, but SIZEOF_LONG_LONG and SIZEOF_VOIDP are 8 bytes. So that truncates half the bits of the hash on such a platform if my understanding is correct. Even is SIZEOF_LONG is 8, LONG2FIX loses the MSB I think, given that not all long can fit the Fixnum range on MRI (should it be LONG2NUM?). Also, I am not sure if it is intended to cast from a unsigned value to a signed value. I tried many things while debugging the rb_str_hash spec on ruby/spec and eventually gave up. This computation looks wrong to me in MRI. For info, here is my debug code: https://github.com/eregon/rubyspec/blob/d62189450c0a56bfcd379e5e505ad097892d2bc7/optional/capi/string_spec.rb#L501-L518 https://github.com/eregon/rubyspec/blob/d62189450c0a56bfcd379e5e505ad097892d2bc7/optional/capi/ext/string_spec.c#L361-L381 and the build result on AppVeyor: https://ci.appveyor.com/project/eregon/spec-x948i/build/629 -- https://bugs.ruby-lang.org/