I doubt it. In the test code you have: ASSERT_ALWAYS (putc ((size >> (j*8)) & 0xFF, fp) != EOF);
should that 0xFF be 0xFFLL or something like that on Windows? Bill. 2010/1/5 Cactus <rieman...@googlemail.com>: > > > On Jan 5, 8:10 am, Cactus <rieman...@googlemail.com> wrote: >> On Jan 4, 8:02 pm, Cactus <rieman...@googlemail.com> wrote: >> >> > On Jan 4, 6:56 pm, Bill Hart <goodwillh...@googlemail.com> wrote: >> >> > > It looks like we have the following in mpir.h: >> >> > > #if defined (_CRAY) && ! defined (_CRAYMPP) >> > > /* plain `int' is much faster (48 bits) */ >> > > #define __GMP_MP_SIZE_T_INT 1 >> > > typedef int mp_size_t; >> > > typedef int mp_exp_t; >> > > #else >> > > #define __GMP_MP_SIZE_T_INT 0 >> > > typedef long int mp_size_t; >> > > typedef long int mp_exp_t; >> > > #endif >> >> > > So on most linux machines we'll have mp_size_t is a long. That is >> > > indeed the problem for Windows. I think it is safer to guard it to >> > > prevent any possibility of issues. I'm unsure what happens on Sparc. >> >> > I will also have to add other options to __GMP_MP_SIZE_T_INT to set >> > the right follow on definitions in gmp-impl.h: >> >> > #if __GMP_MP_SIZE_T_INT >> > #define MP_SIZE_T_MAX INT_MAX >> > #define MP_SIZE_T_MIN INT_MIN >> > #else >> > #define MP_SIZE_T_MAX LONG_MAX >> > #define MP_SIZE_T_MIN LONG_MIN >> > #endif >> >> I have now tried this and, unfortunately, one test (mpz io_raw) fails >> when MPIR calls realloc with a current memory block of 8 bytes and a >> new block request of 1 byte. >> >> It _ssems_ (I am not yet sure about this) that Windows doesn't bother >> to reallocate in this situation and MPIR sees this as an error. > > I now know what is going on here - mpz.inp_raw is aksing for a _lot_ > of memory (this was not obvious because the long long value was not > being printed out). > > GNU MP: Cannot reallocate memory (old_size=8 new_size=4294967296) > > It si attempting to read in a 2^32 - 1 byte number so 4GB is what it > would need. > > It hence turns out that this issue has been there all along - it was > the truncation of the memory request that has previously prevented it > showing up previosuly. > > But does the raw input test really test a file input of this size? > > 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. > > > >
-- 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.
