On 12 October 2012 22:13, Brian Gladman <b...@gladman.plus.com> wrote: > -----Original Message----- From: Bill Hart > Sent: Friday, October 12, 2012 10:05 PM > > To: mpir-devel@googlegroups.com > Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released > > [snip] > >> >> I have a feeling we need to go back to some underlying principles here. >> >> So for a start, intmax_t and uintmax_t on Windows are defined in stdint.h >> (C) or cstdint (C++) and they can only be used on MSVC10 and later. They >> can be detected by looking for the stdint.h guard _STDINT which can hence >> be >> used to remove code and tests of these types. > > > The _STDINT guard is define in stdint.h. So you need to include it > before you can check if it is available. > > ======================================== > In test code yes but not in mpirxx.h, where we can use > > #ifdef _STDINT > code using uintmax_t and/or uintmax_t > #endif > ========================================
But this will always exclude that code unless stdint.h is included somewhere. So where is it going to be included? It would have to be included in our test code, which we can't do. It's also a massive burden on the user to test whether stdint.h is available, and to know to include before mpirxx.h if it is. Anyhow, I've simply removed c++ support on linux for intmax_t operators, which now works fine on both x86_64 and ia64. > > > On linux configure does a test by trying to compile a program with a > stdint.h feature. If it is found it sets HAVE_STDINT_H to 1 in > config.h. But the user does not have access to this. So the only way > to guard for stdint.h is to either test that the compiler is fully C99 > compliant, for which there are defines. Or we can go through compiler > by compiler and work out when it is available. > >> >> I agree with your concern about config.h and HAVE_? defines in user code >> so >> we need an alternative way of guarding code and tests where these are >> used. > > > In general these don't exist. Configure creates config.h by compiling > actual programs and seeing what doesn't crash the compiler. You can't > do that with guards. > > The only solution is to not supply features which are not available on > all systems, or to only supply them when they are guaranteed to be > supported. For linux, this means what I said. We have to remove c++ > support for intmax_t functions. The linux C++ compilers simply don't > make it possible to support this. Fortunately it isn't needed anyway > because intmax_t is always either long or long long on linux. > > ======================================== > > Then we can use an _MSC_VER guard around this stuff to exclude it on *nix. > > Let me know if (and where) you need this and I will do it. Ok. I've just done this right now. So, does it all work on Windows now? Bill. > > 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-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. > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. 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.
