[PATCH] [RFC] Clarify the behavior when interrupting the execution of a caller-provided memory allocation function

[John Scott]

Hi,

Feedback from C++ folks especially would be appreciated, as I'm not
familiar with that language. I'll hereafter speak on the implications
only for C.

The documentation says that longjmp()'ing out of a caller-provided
allocation function is undefined behavior, but as this functionality is
provided by the C standard library, GMP has no means to cause it to fail
to work, and indeed it does work. However, this will leave GMP in an
inconsistent state, such that no GMP function (without exception) should
be called.

This documentation change affirms the status quo, and clarifies that
longjmp()'ing out of an allocation function is not inherently undefined.
The particular choice of language in this change is to be agnostic with
respect to the C++ interface.
--- gmp.texi	2022-11-05 16:28:52.635513649 -0400
+++ gmp.texi.2	2022-11-05 16:40:46.458551118 -0400
@@ -7494,9 +7494,9 @@
 another question though.
 
 There's currently no defined way for the allocation functions to recover from
-an error such as out of memory, they must terminate program execution.  A
- at code{longjmp} or throwing a C++ exception will have undefined results.  This
-may change in the future.
+an error such as out of memory, they must terminate program execution or cease GMP usage.  A
+ at code{longjmp} or throwing a C++ exception and causing any subsequent GMP function to be called
+is undefined.  This may change in the future.
 
 GMP may use allocated blocks to hold pointers to other allocated blocks.  This
 will limit the assumptions a conservative garbage collection scheme can make.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: This is a digitally signed message part
URL: <https://gmplib.org/list-archives/gmp-discuss/attachments/20221105/d1e5f165/attachment.bin>