On Tuesday 08 November 2011 16:44:19 Bob Smith wrote: > On 11/4/2011 8:01 PM, Marc wrote: > > On Nov 5, 12:23 am, Bob Smith<bsm...@sudleyplace.com> wrote: > >> Using MPIR 2.4.0, I'm substituting my own memory allocator which gets > >> called from tal-reent.c in __gmp_tmp_reentrant_alloc. The code in that > >> function doesn't check to see if the allocation failed and immediately > >> writes into the memory, allocated or not. > >> > >> How should I indicate that the allocation failed so your code and my > >> code may recover cleanly? > > > > You can't, but the closest you can get is to throw an exception (note > > that with gcc it may require compiling mpir with -fexceptions). > > How does throwing an exception (to be caught in my code that calls some > MPIR function) allow the MPIR code to clean up after itself? Isn't this > likely to create a memory leak? > >
Hi There are a number of possible solutions which all have quite big problems with them 1) change all mpir fn's to return an error code indicating out of memory , this would need all the mpir fn's to be changed to detect this , and would also break the ABI and compatibility 2) change all the mpir fn's to accept a param with preallocated memory , again same problems as above plus you would need to know in advance how much memory each fn uses 3) change the mem allocator to record all allocations in a table , and also when the new mem allocator fail to allocate memory it setjmp's to a new fn which unallocates all entry in the table and says "out of mem" This may only miss mem allocated on the stack though , have to check on this one 4) define macros,fn's in mpir which give the max amount of mem needed by every fn , and any app calling any fn in mpir would need to check before each call , this would keep backwards compatibilty and require only simple changes to the app , this is my favorite , but we would have a lot of quite horrendous macros to define , and it's a pretty big job , if we make the macro's/fn's recursive then this would be much easier although it would be slow for small numbers Jason -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
