GMP pow 中的溢出处理

（我只是 GMP 库的间接用户，主要通过swi-prolog and yap。但我对解决这个问题非常感兴趣。）

当使用大得离谱的值执行求幂时，主机系统或 GMP 不再能够适当地处理溢出。我已经与上述系统的开发人员交谈过，但他们没有看到解决此问题的简单方法。

其他 GMP 系统/用户是否知道此问题？您如何处理此类溢出？

作为健全性检查，首先测试 7^7^7 的值，它应该是： 375982...32343

在 32 位系统上，例如查询?- X is 13^1150000000.产生这样的溢出。 YAP 给出的内容如下：

GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /opt/gupu/src/yap-6.3/narch-gupu2/yap...done.
(gdb) run -f
Starting program: /opt/gupu/src/yap-6.3/narch-gupu2/yap -f
YAP 6.3.2 (i686-linux): Sun Nov 11 04:19:37 CET 2012
?- X is 13^1150000000.

Program received signal SIGSEGV, Segmentation fault.
0x001638d8 in ?? () from /usr/lib/libgmp.so.3
(gdb) bt
#0  0x001638d8 in ?? () from /usr/lib/libgmp.so.3
#1  0x00164470 in __gmpn_mul_fft () from /usr/lib/libgmp.so.3
#2  0x001646c2 in __gmpn_mul_fft_full () from /usr/lib/libgmp.so.3
#3  0x00165f28 in __gmpn_sqr_n () from /usr/lib/libgmp.so.3
#4  0x0014b58b in __gmpz_n_pow_ui () from /usr/lib/libgmp.so.3
#5  0x0014c4a1 in __gmpz_pow_ui () from /usr/lib/libgmp.so.3
#6  0x080c4a1d in Yap_gmp_exp_int_int (i1=13, i2=1150000000) at ../C/gmp_support.c:939
#7  0x0815f9df in p_exp (t1=, t2=3082051592) at ../C/arith2.c:609
#8  0x080b1f19 in Eval (t=0) at ../C/eval.c:147
#9  0x080b2251 in p_is () at ../C/eval.c:186
#10 0x0806b56a in Yap_absmi (inp=0) at ../C/absmi.c:6912
#11 0x080b3655 in exec_absmi (top=) at ../C/exec.c:1002
#12 0x080b3b1f in do_goal (t=, CodeAdr=, arity=, 
    pt=0x0, top=1) at ../C/exec.c:1068
#13 0x080b3d1d in Yap_RunTopGoal (t=135918154) at ../C/exec.c:1291
#14 0x08061a6f in YAP_RunGoalOnce (t=135918154) at ../C/c_interface.c:2511
#15 0x0805c2f5 in do_top_goal (argc=2, argv=0xbffff4c4) at ../console/yap.c:84
#16 exec_top_level (argc=2, argv=0xbffff4c4) at ../console/yap.c:131
#17 main (argc=2, argv=0xbffff4c4) at ../console/yap.c:172
(gdb) 
  

编辑：对于 64 位系统也是如此；像这样：

Welcome to SWI-Prolog (Multi-threaded, 64 bits, Version 6.3.5)
Copyright (c) 1990-2012 University of Amsterdam, VU Amsterdam
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it under certain conditions.
Please visit http://www.swi-prolog.org for details.

For help, use ?- help(Topic). or ?- apropos(Word).

?- X is 3445^2^62.
gmp: overflow in mpz type
Abort

However,

?- X is 2^2^63.
ERROR: Out of global stack
?- X is 2^2^62.
gmp: overflow in mpz type
Abort

从下面开始：

?- X is 2^2^36.
ERROR: Out of global stack
?- X is 2^2^37.
gmp: overflow in mpz type
Abort

因此，如果数字足够大，则 SWI 会检测到错误 - 因此可以由 SWI 处理（错误：消息由 SWI 处理）。

并不是真正的答案，而是 SWI-Prolog 的作用的解释。首先，它估计是否 可能会发生溢出。如果确定，则会在调用 GMP 之前引发错误。否则，它 依赖 GMP 分配挂钩并在失败时执行 longjmp()。它会跟踪哪个 为什么进行分配并释放为中止的 GMP 操作分配的内存。它 之所以能够做到这一点，是因为记忆永远不会永久受到 GMP 的控制。成功的结果 GMP 计算被复制到 Prolog 堆栈并受 Prolog 内存管理。

这曾经有效，但在最近的版本中不起作用。我怀疑 GMP 估计的大小 如果它知道这会失败，甚至不会调用 malloc() 挂钩。我所需要的只是一种方法来确保始终调用该钩子，即使该值大得离谱。任何大于 size_t 可以表示的东西都可以用 (size_t)-1 调用钩子。

附注由于复制到（较小的）Prolog 运行时堆栈，它的溢出比内存可以存储的要早得多。