Additional memory handler features.

[Victor Shoup]

Thanks. Looks good. I looked searched through the 6.0 manual for "itch",
and they were all of the form mpn_sec, which I guess means they are slower
but resilient to side-channel attacks (which I'm not interested in).

Certainly, this general approach would address all of my immediate concerns,
assuming all the necessary itch/scratch mpn-level routines are available,
and none of them abort for any other reason.

If anyone cares, I can generate a list of all mpn-level routines used by NTL...


On Jan 4, 2015, at 5:27 PM, Marc Glisse wrote:

> On Sun, 4 Jan 2015, Victor Shoup wrote:
> 
>> But I see mention of itching and scratching: could somebody
>> describe what that is or provide a link? Sorry for my ignorance.
>> ....and sorry for the length of this post....
> 
> The general idea is to push all operations that may fail or otherwise
> require customization to user code. There would be a function
> mpn_mul_itch that would tell you how much temporary (scratch) space
> mpn_mul may need, and mpn_mul would take as argument a pointer to a
> buffer of at least this size. Allocation is the user's responsibility. There should already be a few functions or macros with "itch" in their name.
> 
>> [FULL DISCLOSURE: my own, somewhat narrow and selfish goal
>> is to see GMP's mpn-level routines throw exceptions, rather
>> than abort, with no interface changes.  This is what would work
>> best for my own NTL library]
> 
> mpn functions have few reasons to abort. Except for allocation failure,
> as long as you checked the operands before passing them to GMP...
> 
>> [And yet another issue: my understanding is that some OS's actually
>> have rather weird ways of dealing with out-of-memory errors:
>> malloc always succeeds and returns a non-null pointer, but
>> indirecting through that pointer may abort the program.
>> In such a setting, all of this memory-related error handling
>> stuff is pointless]
> 
> Yes. Memory overcommit can often be disabled or mitigated in various
> ways, but it does complicate things (get a better OS ;-)
> 
> -- 
> Marc Glisse