On Dec 10, 10:20 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> Hi Dan,
>
> indeed I had inferred that you had done a *lot* of work to track this bug
> down.
>
> It's not immediately clear how we can cause an error message to be
> output if a custom allocator returns non-aligned pointers.
>
> Two possibilities spring to mind:
>
> 1) Introduce a make check test which checks that the allocator is
> doing what we want. But this relies on the allocator failing to do so
> during the test, which I don't see how to provoke.
>
> 2) Introduce code to align data coming from custom allocators. This
> could probably be done in a handful of cycles per allocation, but
> would still introduce an overhead.
>
> I'm open to further suggestions.
If n-byte alignment for n-byte objects is a target architecture
requirement, this is surely a memory allocation bug and not an MPIR
one.
We might think about some sort of debug mode that adds detection or
defence but I would be against adding overhead that is not going to be
necessary in normal operation (we should, of course, document the
issue).
I would take the view that asking a lot of low level code to defend
against incorrect memory allocation - at possibly heavy cost - is not
the right approach. Whoever has the job of putting a memory allocator
on a machine surely has the responsibility for ensuring that it
complies with any target architecture requirments?
In particular, I would expect to see a debug mode in an allocator for
testing exactly this sort of issue (I thought that Boehm's GC haad
this capability).
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@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.
