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 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel