abort on error - is this being addressed?

[Allan Chandler]

The error flag was going to be a global/thread-specific flag indicating
that memory allocation had failed and that the library had reverted to its
previous state (freeing all memory allocated in the current call from the
client). It was to be used both by GMP in the stack levels above where the
failure occurred (to clean up) and by the application as an indication that
they shouldn't trust the return value.

Any application checking that flag after each call into GMP would know not
to use the result.

And by making it both compile-time and run-time configurable, there would
have been no impact on those who chose to remain with the non-checking
abort-on-allocation-failure method. Compiling with the old abort behaviour
changed nothing, you would still be guaranteed that return from GMP meant a
successful operation (since no return would be allowed in the event of
problems).

So, actually, my suggestion was best summed up as "Please let *me* do some
work in modifying GMP so that it's more usable as a general purpose
library".

But that's okay, I have no skin in this game. I'm quite happy to let you
guys go on your merry way. I cannot in all honesty recommend people use GMP
anymore in robust applications, but I doubt I'll have any lasting effect on
your success or otherwise.

Thanks for listening. Personally, I think it's a shame that you discounted
the suggestions so quickly but everyone's entitled to their own opinion and
life's too short to battle with other developers when I have other concerns
that are easier to manage.

Good luck in future.



                                                                                                                                              
  From:       Torbjorn Granlund <tg at gmplib.org>                                                                                               
                                                                                                                                              
  To:         Allan Chandler/Australia/IBM at IBMAU                                                                                              
                                                                                                                                              
  Cc:         gmp-discuss at gmplib.org                                                                                                          
                                                                                                                                              
  Date:       27/08/2010 04:00 PM                                                                                                             
                                                                                                                                              
  Subject:    Re: abort on error - is this being addressed?                                                                                   
                                                                                                                                              
  Sent by:    tg at gmplib.org                                                                                                                   
                                                                                                                                              





Allan Chandler <allachan at au1.ibm.com> writes:

  If the mpz_mul in your below example cannot alloc memory, it should, in
my
  far-from-humble opinion, clean up any memory it's allocated for the job,
  set the error flag then just return (NULL).  If the client sees fit to
  ignore that, tough luck.

"The error flag"?

And return (NULL) how and where?  You also wrote "I wasn't proposing to
change all the function prototypes to return errors".

I think I can sum up this discussion now:

Please change GMP so that handing of out-of-memry conditions magically
becomes nice and easy.

:-)

--
Torbjörn