bug#16283: 24.2; Built-in function * , used for calculating product, gives wrong output

bug#16283: 24.2; Built-in function * , used for calculating product, gives wrong output

[Mohammed Sami]

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

After starting window Emacs with "emacs -q", when I evaluate (* 1024 1024
1024 1024), I get 0.
(* 1024 1024) works correctly, but repeating '1024' more than two times
gives wrong value.

In GNU Emacs 24.2.1 (i386-mingw-nt5.1.2600)
 of 2012-08-29 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x b s c <return> M-< M-> ( * SPC 1 0 2 4 SPC 1 0
2 4 SPC 1 0 2 4 SPC 1 0 2 4 ) C-u C-x C-e <help-echo>
<return> M-x r e p o r t <tab> <return>



Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set [2 times]

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win
w32-vars tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)

[-- Attachment #2: Type: text/html, Size: 3166 bytes --]

bug#16283: 24.2; Built-in function * , used for calculating product, gives wrong output

[Andreas Schwab]

Mohammed Sami <abdussami101@gmail.com> writes:

> After starting window Emacs with "emacs -q", when I evaluate (* 1024 1024
> 1024 1024), I get 0.

Arithmetic functions generally don't check for overflow.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#16283: 24.2; Built-in function * , used for calculating product, gives wrong output

[Eli Zaretskii]

> From: Mohammed Sami <abdussami101@gmail.com>
> Date: Sat, 28 Dec 2013 23:45:38 +0530
> 
> After starting window Emacs with "emacs -q", when I evaluate (* 1024 1024
> 1024 1024), I get 0.
> (* 1024 1024) works correctly, but repeating '1024' more than two times
> gives wrong value.

A 32-bit build of Emacs cannot correctly do integer math beyond the
value of most-positive-fixnum, whose value is 536870911.  This is a
fundamental limitation of Emacs Lisp, not a bug.

You can work around this bu using floating-point numbers:

  (* 1024.0 1024.0 1024.0) => 1073741824.0

Closing.