On Dec 20, 8:32 pm, Dan Grayson <d...@math.uiuc.edu> wrote:
> I don't see how your "make check" routine could ever even come into
> contact with my custom allocator. Also, it's probably not worth your
> while to try to distinguish a custom allocator from your native
> allocator at run time, as it will waste time.
>
> I suggest checking every pointer returned by the allocator for
> alignment if the compile-time DEBUG flag is defined. (For Macaulay2,
> I debug with that on.) The checking should happen in any routine that
> calls the allocator, and could be implemented by a single macro.
I think this is a good 'defensive programming' suggestion because it
is helps in detecting an exernal issue that can cause MPIR itself to
fail.
It would also help in indicating where such a bug lies and avoid MPIR
itself appearing to be thge source of the problem.
> What about installing a test under "make check" that tries all
> routines with misaligned limbs? Let the misalignment vary. Declare a
> routine to "pass" if it gives the correct answer or crashes or aborts
> the program. Declare the routine to "fail" if it gives an incorrect
> answer. That would have caught the lshift routine I reported. There
> might be some discussion about whether that behavior of mpn_lshift
> counts as a bug.
I don't see this as a useful test since we already _know_ that MPIR
doesn't work when limb data is wrongly aligned.
It isn't intended to work in such situations.
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.
