From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master f18af6c: Audit use of lsh and fix glitches Date: Wed, 22 Aug 2018 20:05:37 +0000 Message-ID: References: <20180821204437.16880.99611@vcs0.savannah.gnu.org> <20180821204439.62390209A6@vcs0.savannah.gnu.org> <53d0c06e-2383-955a-0a17-650fd842b483@cornell.edu> <54e51f66-ba73-d5ef-3839-3986ed759bdc@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1534969148 1081 195.159.176.226 (22 Aug 2018 20:19:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 22 Aug 2018 20:19:08 +0000 (UTC) Cc: kbrown@cornell.edu, emacs-devel@gnu.org To: eggert@cs.ucla.edu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 22 22:19:04 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsZap-000080-I2 for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2018 22:19:03 +0200 Original-Received: from localhost ([::1]:60655 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsZcw-0007XQ-29 for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2018 16:21:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsZbm-0007Un-KB for emacs-devel@gnu.org; Wed, 22 Aug 2018 16:20:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsZOU-0003Y1-Bb for emacs-devel@gnu.org; Wed, 22 Aug 2018 16:06:19 -0400 Original-Received: from mail-lj1-x242.google.com ([2a00:1450:4864:20::242]:38838) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fsZOT-0003W0-Sv for emacs-devel@gnu.org; Wed, 22 Aug 2018 16:06:18 -0400 Original-Received: by mail-lj1-x242.google.com with SMTP id p6-v6so2381231ljc.5 for ; Wed, 22 Aug 2018 13:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3s901QvNvVwevyakbUV4Xy2Jv/KZH1BpQxHmF11sHxY=; b=Idmof961NodP3NRY6QHoJpZU5HLzz4jHRsJNZ7wONfnQ03uU91DcW2VMLULrJKYV3d P98yVqLcJdYGu3YMUFkhHHi6dmUKHn8YeCR6HOwDGe56fSj/GrREkkJ6PBHzxLLy6yyV fSFcpcxm0Qd9sifC6mrcBdo8lzYMqg9X2WPj2zUgzz44IpA7nvyZVzNqqEgeWdLUwsI8 y01nJfVgrMxYzybig9fvlY6rwnGG/8kbLKfACZRmy6bb7jtXwKWpEiEe/uusOOc2xkJ5 /NTWI+eTSWFGNF8CBT57FprhjAqdQ0NmjMhchHGr3uRW95zWZtIaKiSeUtl5l+t8Fenj g8fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3s901QvNvVwevyakbUV4Xy2Jv/KZH1BpQxHmF11sHxY=; b=XPD5LSPqh8qIL9RwcN8wmEnEj23TjxfPdEYNeebKXeZeq/0A2rwYW07wHE8zBAQaso DZsxS6gxn77aE3p9EVEuaEHbRKAQRtiZr2A66E1upKhrcJx0jJn+2+fZYMgf0rgqmic8 I50yEMAAHGLgB/MQ+JTigas7VyH1f8YEo3Z6rHnhETGRvZPJUalUYdhKJejfxY3LBcQ5 YIBj48C/5TpuIoGdBsCMp46T/VAa8v7y2UXdv4x/wb6iIzRRSlMtX12T2DOq8aBmoPxE iEtT/uofrslMoWRjUX4jLZWE4oIP0Izobl5Hbnx2un4hRPGkmAqzpFVhqCW2EXlnzXxu 3O/A== X-Gm-Message-State: APzg51BgCz115MDuIWqretzTW4v3Uf04oF0gCV/XIutmNeardYX5UDck d+stQZ9Ks7uRT3FaxwDZl8J6mw/glklOF+KYYcc= X-Google-Smtp-Source: ANB0VdZNOjOSDJW+zH0yH8tfHxX2so3soz9wxu8Hwe8ZWNC/EYZhc2ojICJy6KGKqkqqg5/31kDaSNxdlCC8z8hffjE= X-Received: by 2002:a2e:8652:: with SMTP id i18-v6mr3127622ljj.43.1534968376563; Wed, 22 Aug 2018 13:06:16 -0700 (PDT) In-Reply-To: <54e51f66-ba73-d5ef-3839-3986ed759bdc@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::242 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228829 Archived-At: On Wed, Aug 22, 2018 at 5:27 PM Paul Eggert wrote: > Pip Cet wrote: > We get some of that effect already in 32- vs 64-bit builds. Perhaps you'r= e right > and we would benefit from artificially small fixnums, or from debug build= s that > warn about eq misuse. Well, it's harder to implement this than I thought at first, since we want to change `eq' and `most-positive-fixnum' but not EQ and MOST_POSITIVE_FIXNUM. > > That said, vc-hg.el doesn't contain any suspicious-looking instances > > of `eq', `memq', or `hash' > Unfortunately that doesn't seem to be quite right. I looked and found one > incorrect (though quite unlikely to fail) use of eq. I changed it to eql = as part > of the attached patch, which I installed. No objections to that patch, but `eq' is correct in that code: string length is limited by STRING_BYTES_BOUND, which is <=3D MOST_POSITIVE_FIXNUM, so flen will always be a fixnum. It's also handed to fixnum-only functions immediately afterwards, so even if we allowed non-fixnum-length strings we'd get, at worst, a different signal. > > As for `eq' and `eql', what I thought Stefan proposed was to keep a > > hash value in struct Lisp_Bignum, which is calculated lazily the first > > time the bignum is compared to another bignum with `eq', at which > > point we might as well point out to the user that portable code would > > require `eql'. That sounds to me like it would be much cheaper than a > > hash table, but if there are objections to it we can still implement > > it without guaranteeing it for the future in the documentation. > > It might be helpful to have that in a debugging build. > I am still leaning more towards hash tables, though; It's precisely the opposite for me: I'm leaning towards hash tables in debugging builds, where "which bignums currently exist" is a useful question to ask, and lazy hashing in production builds, where make_number is called often and (soon) shouldn't actually walk through the bignum again to make a copy of it or calculate its hash value. >at least, I want to time > them to see how much they actually cost in typical practice. I suspect th= e cost > is rather small, and if so it may well be worth it to avoid hassles like = the > eq-vs-eql glitch that I just now fixed in vc-hg.el. I suspect the answer is they're cheap in "typical" practice because bignums don't appear there, and expensive enough in atypical situations (cryptography? number theory? G=C3=B6del coding?) to make some applications resort to unnecessary and danger-prone C libraries. And we're comparing two proposals which would make eq-vs-eql a non-issue; one would slow down make_number (significantly, I believe, unless we keep the current behavior which includes an unnecessary memcpy), the other would slow down `eq' and possibly `EQ' to require a tag bit check to catch bignum-on-bignum comparisons. That's an xor (unless we change some other things) and a test insn if we give bignums ("vectors with overloaded EQ behavior") their own tag value (yay, now I've used up the tag bit you've freed for the second time). [In fact, I like the idea of extending this to reserving one tag value for "it's complicated" objects, which may but don't have to overload primitives. All the primitives would check OVERLOADEDP(arg), a simple and cheap tag bit check, before doing the right thing for primitive objects. Think of all the number systems we could still implement.]