GNU bug report logs - #32463
27.0.50; (logior -1) => 4611686018427387903

Previous Next

Package: emacs;

Reported by: Katsumi Yamaoka <yamaoka <at> jpl.org>

Date: Fri, 17 Aug 2018 03:31:02 UTC

Severity: normal

Found in version 27.0.50

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #128 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32463: 27.0.50; (logior -1) => 4611686018427387903
Date: Thu, 23 Aug 2018 00:27:55 +0100
On Tue 21 Aug 2018, Paul Eggert wrote:

>> Does this limit apply to bignum values in lisp objects, or to
>> intermediate values inside libgmp, which may require extra space ?
>> The documentation for `integer-width' should make this clear.
>
> integer-width applies only to Lisp objects. I'm not sure we should be exposing
> internal details of the interpreter to the Lisp user, which includes the sizes
> of its internal temporaries. If a need shows up for it we can do it, but I
> don't see the need.

The current documentation is uninformative:

  Maximum number of bits in bignums.
  Integers outside the fixnum range are limited to absolute values less
  than 2**N, where N is this variable’s value.  N should be nonnegative.

This says plenty abut fixnums, but does not mention that anything larger
than fixnum range is represented as a bignum. For users who are new to
all of this, it is important to state that.

I think it is worth mentioning that intermediate computations not visible
to lisp may use slightly larger bignums, and to make it clear that this
is a soft limit intended to prevent misbehaviour of the runtime.

    AndyM





This bug report was last modified 6 years and 320 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.