Re: [Emacs-diffs] master f18af6c: Audit use of lsh and fix glitches

[Pip Cet <pipcet@gmail.com>]

On Wed, Aug 22, 2018 at 5:27 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> Pip Cet wrote:
> We get some of that effect already in 32- vs 64-bit builds. Perhaps you're right
> and we would benefit from artificially small fixnums, or from debug builds 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 <=
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 the 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ödel 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.]