MPIR is 250,000 lines of code. Does this possibly answer your questions? We have 1 (ONE) Windows developer, and one hell of a lot of users. It would certainly help if people using MPIR on Windows were able to contribute back to the project in the form of patches (preferably in the form of GitHub Pull Requests).
It's my hope that Microsoft making Ubuntu available on Windows and projects like Visual Studio Code will increase the ratio of developers to users of Open Source software on Windows. Bill. On 21 May 2016 at 18:36, <terry_ly...@lyonstech.net> wrote: > > > On Monday, 24 October 2011 20:31:02 UTC+1, Cactus wrote: >> >> You are right - size_t is supposed to be 64-bits on Windows x64. But to >> get this behaviour, you have to define _WIN64 during the build process. >> >> I have been caught by this so many times because _WIN64 is supposed to >> be a predefined macro, onr that is automatically defined for 64-bit builds. >> >> >> But, as far as I can see, it has to be user defined. >> >> Brian >> >> > Sorry this is late in the day, but surely defining _Win64 is required > internals to getting an x64 build? In Intel MKL at least ILP64 is the > usual notation for 64bit integers on x64 - while LP64 refers to using 32 > bit integers in an x64 environment. This is orthogonal to the language used > in this thread. > > At the risk of opening old discussions, one point I never understood is > the trouble over 32bit and 64 bit integers in GMP/MPIR. It seems this is > still (2016) causing trouble in some parts of the testing code. The mkl > solution is one way, with distinct ILP64, LP64, WIN32 libraries; but > ?unless I am missing something, it seems that all MPIR wanted was integers > that are 64 bit on 64 bit machines and 32 bits on 32 bit machines. Surely > this configuration is always available from the original unix code via a > global replace of unsigned int by std::size_t and int by std::ptrdiff_t in > <cstddef>. > As far as I can see this is truly system independent and standard > compliant. > > If one wants precise bit length integers then int32_t and int64_t seem > the way to go - as they are (rather elegantly) only defined in the > standard if the OS actually has those lengths (which it may not since a > byte may not be 8 bits). > > The subtle flaws referred to in MPIR documentation really come neither > from windows or unix but from using a non-standard defined behaviour of int > when really this is not necessary (although understandable). The type int > should probably not appear anywhere in the code of MPIR except for input > and output to other api's (such as output) where it should be checked for > overflow using safeint<> or similar. I worry that builds (at least of > tests) still show some 64bit<->32bit conversion warnings. I suppose now > that the underling library code is really OK. I certainly believe/assume > that if I use strings to serialise and pass long integers between machines > in MPI there is no danger of lost information. In fact I think MPIR::GMP is > a great tool. > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mpir-devel+unsubscr...@googlegroups.com. > To post to this group, send email to mpir-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/mpir-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
