Re: Better behaviour for interactive apps on leaf overflow?

Hello again  --

OK, let me be a bit more explicit. There is no way as it stands to prevent
GMP from calling abort() with overflow of a leaf. This is a bug for our use
case, a long-running interactive program that needs to crash as little as
possible. Please add a way to prevent GMP from calling abort() when
anticipated overflow of a leaf is encoutered.

Best,

Aidan

 Ar an deichiú lá de mí Aibréan, scríobh [email protected]: 

 > Your request to the gmp-bugs mailing list
 > 
 >     Posting of your message titled "Better behaviour for interactive
 > apps on leaf overflow?"
 > 
 > has been rejected by the list moderator.  The moderator gave the
 > following reason for rejecting your request:
 > 
 > "The moderator found no bug report in your message."
 > 
 > Any questions or comments should be directed to the list administrator
 > at:
 > 
 >     [email protected]

 Ar an deichiú lá de mí Aibréan, scríobh Aidan Kehoe: 

 > 
 > Hello!
 > 
 > We’ve been using libgmp for our bignum support in XEmacs for a decade or so
 > now, thanks to Jerry James, one of our more active developers. XEmacs Lisp is
 > in spirit a Lisp-2 close in philosophy and history to Common Lisp, and it’s
 > correct and pleasant to have good bignum support.
 > 
 > One of our design (and implementation!) goals for XEmacs Lisp is that it
 > should be impossible for Lisp to crash XEmacs, something very important in
 > preserving our users’ data. We supply our own allocation functions to gmp and
 > handle our failures ourselves to minimise the risk of that happening. But, it
 > is still perfectly possible for Lisp to do something like this, where lsh is
 > the bitwise left shift operation, and most-positive-fixnum is 2 to the 30th
 > minus one:
 > 
 > (lsh (lsh most-positive-fixnum #xFFFFFF80) #xFFFFFF80)
 > 
 > On a 32-bit machine this will eventually fail with the following message:
 > 
 > (gdb) r -batch -eval "(lsh (lsh most-positive-fixnum #xFFFFFF80) #xFFFFFF80)"
 > Starting program: /Sources/xemacs-21.5-integer-length/src/xemacs -batch -eval "(lsh (lsh most-positive-fixnum #xFFFFFF80) #xFFFFFF80)"
 > gmp: overflow in mpz type
 > Program received signal SIGABRT, Aborted.
 > 0x95187c5a in __kill () from /usr/lib/libSystem.B.dylib
 > (gdb) 
 > 
 > Now, this abort isn’t wrapped, gmp calls it unconditionally in
 > realloc.c:_mpz_realloc(). This is frustrating for XEmacs; from our
 > perspective, we’d like to throw an error in this situation in the same way we
 > do when we divide by zero, rather than crash the entire process and have the
 > user lose so much of his or her state. Our garbage collector will take care of
 > the lost memory. 
 > 
 > Best,
 > 
 > Aidan Kehoe


-- 
‘Tramadol is further fed to cattle […] when working them […] (as draft
animals) so that the animals do not get tired quickly. …’
	— Angewandte Chemie, Sept 2014, describing the social context of
	(synthetic) tramadol having been found in Cameroon tree roots.

_______________________________________________
XEmacs-Beta mailing list
[email protected]
http://lists.xemacs.org/mailman/listinfo/xemacs-beta