On Mon, Jan 5, 2015 at 12:08 AM, Niels Möller ni...@lysator.liu.se wrote:
Victor Shoup sh...@cs.nyu.edu writes:
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 idea
Fredrik Johansson fredrik.johans...@gmail.com writes:
How would this work with functions that allocate a variable amount of
memory depending on the values of the inputs? Wouldn't you always have
to allocate for the worst case?
It has to be sufficient for the worst case. There are also some
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,
Thanks. This would more-or-less solve all my problems,
if and when it all gets implemented. I don't find such functions
right now in the GMP manual.
On Jan 4, 2015, at 6:08 PM, Niels Möller wrote:
Victor Shoup sh...@cs.nyu.edu writes:
But I see mention of itching and scratching: could
Marc Glisse marc.gli...@inria.fr writes:
Er, people have been using the custom allocators for (possibly
imperfect) recovery on allocation failure for years. PPL's configure
script complains if gmp was compiled without -fexceptions for that
reason. Apparently SWI-Prolog uses longjmp
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
Victor Shoup sh...@cs.nyu.edu writes:
First, it seems to me that Marc's example of custom allocators
can perhaps best be viewed as a work-around of GMP's lack of
proper error handling. So one should be careful not to
conflate error handling with memory management.
Maybe. Nevertheless, I'll
Victor Shoup sh...@cs.nyu.edu writes:
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 idea is that instead of having gmp allocate temporary storage, it
should have a
On 5 Jan 2015, at 10:08 am, Niels Möller ni...@lysator.liu.se wrote:
Of course there are also some drawbacks. It makes life more complicated
for applications, and the implementation of functions like mpn_mul_itch,
which interact with pretty complex algorithm choice machinery, is going
to be
On 2015-01-04 11:41:02 -0500, Victor Shoup wrote:
So let's ignore custom memory allocators for a minute,
and just think about error handling.
There are just a few viable approaches:
1) abort with error message (current approach)
2) return codes (the traditional C approach)
3) C++
I completely agree with Niel's assessment of Victor's options (1) - (4)
for handling errors.
Recall the following from Torbjörn's original post:
There are real scenarios where one would want different sets of
allocation functions. E.g., many libraries use GMP. Some of them have
their own
On 2015-01-04 23:17:16 +, David Harvey wrote:
On 5 Jan 2015, at 10:08 am, Niels Möller ni...@lysator.liu.se wrote:
Of course there are also some drawbacks. It makes life more complicated
for applications, and the implementation of functions like mpn_mul_itch,
which interact with pretty
You seem already convinced there are potentially significant benefits
for handling larger, off-stack temporary heap allocations differently
from other heap allocations.
... a largish memory area with only start address, size, and stackpointer
needed to keep track of the allocation state, ...
You insist on discussing on a quite abstract level, ignoring Niels'
requests for a bit of concreteness.
Tell you what, memory allocation is required by any non-trivial library.
If this in your opinion breaks the do one thing, and do it well rule,
then you won't like any software, not even hello
t...@gmplib.org (Torbjörn Granlund) writes (replying to David Warme, not
me):
You insist on discussing on a quite abstract level, ignoring Niels'
requests for a bit of concreteness.
Honestly, I don't fully understand why we have the customizable
allocation at all. I'm aware of only one real
What I asked was what problem is solved by finer granularity
than memory with and without pointers. I kind-of dislike adding very
gmp-specific arguments to the allocation functions, so I'd be happy to
see a *concrete* use case where it solves a real problem.
First of all, there are few things
David M. Warme da...@warme.net writes:
But I'm not ocnvinced this level of granularity makes sense. Which
problem does it solve?
Limb arrays have the potential to receive special treatment by the
memory manager.
Agreed. What I asked was what problem is solved by finer granularity
than
17 matches
Mail list logo
