[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32463: 27.0.50; (logior -1) => 4611686018427387903

From: Paul Eggert
Subject: bug#32463: 27.0.50; (logior -1) => 4611686018427387903
Date: Tue, 21 Aug 2018 02:40:34 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Pip Cet wrote:

I think we can be clever and wrap calls to mpz_mul_2exp (which can
create arbitrary bignums) and whatever Fexpt uses....  I'd suggest a much
lower limit until/unless the C-g issue is fixed, perhaps overridable
by a user preference if people really want to use big bignums.

Yes, this sounds good. After stressing Emacs with bignums for a bit, I found that it was too easy to get Emacs to abort or hang by creating large bignums.

I'm not sure what a reasonable limit would be, but I think a global
limit of bignum size to something that allows for "immediate"
computations would be best.

I installed the attached patch to do that. It tentatively defaults to a limit of 2↑↑5 (i.e., 2**65536) for bignums, overrideable by setting a new variable 'integer-width' that defaults to 65536. This default should be big enough for almost all Emacs applications and should avoid issues of aborts and hangs.

Attachment: 0001-Avoid-libgmp-aborts-by-imposing-limits.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]