GNU bug report logs - #33765
emacs-26.1-mac-7.4; (expt 2 140) ; produces 0 in scratch buffer, unexpectedly

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van L <van <at> scratch.space>
Cc: 33765 <at> debbugs.gnu.org
Subject: bug#33765: emacs-26.1-mac-7.4; (expt 2 140) ; produces 0 in scratch buffer, unexpectedly
Date: Mon, 17 Dec 2018 17:53:37 +0200

> From: Van L <van <at> scratch.space>
> Date: Mon, 17 Dec 2018 08:24:21 +1100
> Cc: bug-gnu-emacs <at> gnu.org,
>  33765 <at> debbugs.gnu.org
> 
> > The correct value cannot be represented in an Emacs fixnum.  What did you expect Emacs to do?  IOW, what would be the "expected" result, given the limited range of integers we can represent?
> 
> I expect no answer and an error out with an informative explanation if asked for, when Emacs is unable to do.

Since we already do better than that on the master branch (including
signal an overflow error when even a bignum cannot represent the
result), I think this bug is already solved and should be closed.

> A helpful place to explain the versioning policy would be a file in the emacs/etc directory.
> 
> Version 26 means stable, 27 means unstable is my guess.

We don't have stable and unstable releases.  We have a release branch
and a development branch, and their roles are described in CONTRIBUTE.

Previous Next

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