|
From: | Paul Eggert |
Subject: | Re: [Emacs-diffs] master f18af6c: Audit use of lsh and fix glitches |
Date: | Wed, 22 Aug 2018 10:27:37 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
Pip Cet wrote:
Maybe we ought to warn (in debug builds) about eq being used to compare several integers, at least one of which is outside a narrow interval of guaranteed fixnums (and ditto for memq and hashtest_eq). I wonder whether Emacs would even build with MOST_POSITIVE_FIXNUM = 0x100000, but it might be worth it to try and run it that way...
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.
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.That said, vc-hg.el doesn't contain any suspicious-looking instances of `eq', `memq', or `hash'
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; 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.
0001-Make-vc-hg-safe-for-bignums.patch
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |