On Tue, 24 Jan 2012 07:37:09 -0800 Case Van Horsen > On Tue, Jan 24, 2012 at 5:59 AM, Cactus wrote: > >> To reinforce that these new types are MPIR specific, should they > >> be called mpir_ui/mpir_si? > > > > I had exactly the same idea a few days ago - I am inclined to do > > this. > A couple more ideas... > > Can we define a macro (HAVE_MPIR_SI ?) to unambiguously detect if > mpir_si/mpir_ui is available?
I can put HAVE_MPIR_UI and HAVE_MPIR_SI into mpir.h if this would do the trick. > For better backwards compatibility, should mpir_si/mpir_ui always > default to long unless USE_MPIR_SI (or some other descriptive name) is > defined before mpir.h/gmp.h is included? Right now these types are always long with only one exception - Windows x64, which is detected with the define _WIN64. I am not that keen on removing the default of using 64-bit integers on Windows x64 but we could allow this to be turned off by defining, say, NO_MPIR_INTS: #if defined( _WIN64 ) && !defined( NO_MPIR_INTS ) .... #else .... #endif > The only compatibility issue I encounterd was trying to explicitely > get a long on 64-bit Windows. I had to downcast the results of > gmp_get_si(). Would it make sense to add > mpir_get_slong/mpri_get_ulong? Yes, I can add: #ifdef _WIN64 #define mpz_get_ulong(x) ((unsigned long)mpz_get_ui(x)) #define mpz_get_slong(x) ((long)mpz_get_si(x)) #endif to solve this. Brian -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/IRQHAeL7MukJ. To post to this group, send email to mpir-devel@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.
