On 12 October 2012 23:27, Brian Gladman <[email protected]> wrote: > -----Original Message----- From: Bill Hart > Sent: Friday, October 12, 2012 11:23 PM > > To: [email protected] > Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released > > On 12 October 2012 23:19, Brian Gladman <[email protected]> wrote: >> >> -----Original Message----- From: Bill Hart >> Sent: Friday, October 12, 2012 11:11 PM >> >> To: [email protected] >> Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released >> >> On 12 October 2012 23:06, Brian Gladman <[email protected]> wrote: >>> >>> >>> -----Original Message----- From: Bill Hart >>> Sent: Friday, October 12, 2012 10:58 PM >>> >>> To: [email protected] >>> Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released >>> >>> [snip] >>> >>> There are a couple more instances of _MSC_VER guards in mpirxx.h. Did >>> you only mean to change two of them? >>> >>> ======================== >>> No, I meant to do all of them - I'll go through this again. >>> >> >> OK, I believe there are two more instances. >> >>> By the way, I have been going through the tests that use config.h and I >>> have >>> done about ten of them so far and I haven't found even one that actually >>> needs config.h on Windows (i.e the test compiles and runs when this >>> include >>> is omitted). >>> >> >> Well, we can try removing them and adding them back in if they are >> actually needed. Probably they were only added for this specific >> problem, which we've now resolved by simply excluding the relevant >> code on Linux. >> >> ============================= >> Ok, I'll go through them and take them out if they are not needed on >> Windows. You can then test is this breaks the tests on *nix. >> >> On the print format issue for mp_limb_t, mp_limb_unsigned_t, intmax_t and >> uintmax_t, mp_bitcnt_t, ... should we add format specifiers (or macros) >> in >> gmp_h.in where these types are defined? >> > > Yeah, but I think the people who came up with this new "feature" of C > compilers sat around a table late one night drinking vodka and decided > to implement the most useless and most difficult to rectify "feature" > their evil brains could concoct. So I am not convinced there are > portable macros which actually work everywhere. So we are probably > wasting our time trying. > > ======================== > > On Windows we could at least set up "%ld" or "%lld" depending on whether > limbs (and other types) are 32 or 64 bits. > >
Yes. Though this is not the issue I was talking about. We compile on *nix with -std=gnu99, and the newer compilers complain that we aren't using the new C99 format specifiers for intmax_t and size_t. Of course these are not defined on older compilers, even if they do support the -std=gnu99 option. So what we are supposed to do about it is anyone's guess. Eventually these compiler warnings, which are numerous, will become compiler errors. At that point I suggest we write our own compiler. Bill. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
