On 12 October 2012 21:57, Brian Gladman <b...@gladman.plus.com> wrote: > -----Original Message----- From: Bill Hart > Sent: Friday, October 12, 2012 9:45 PM > > To: mpir-devel@googlegroups.com > Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released > > [snip] > > >> Going back to stdint.h, I think the assumption is that this needs to be >> included by the user before the mpirxx.h include so we should not include >> it >> in mpirxx.h >> > > But we can't do this on systems which don't support stdint.h. This was > not part of the standard before C99. Some systems before C99 partially > implement it, e.g. MSVC. > > ====================================== > > So we can't 'not include it' - i.e. you believe that we must include it - I > am now completely confused. >
I mean in the test code. We can't include stdint.h in the test code before mpirxx.h because on some systems it is not supported or not fully implemented. > >> On Windows the C++ header for LLONG_MAX is <climits> - I am surprised that >> this doesn't exist on *nix. > > > It exists, but is only partially implemented before c++0x compliant gcc. > > That is also true of <cstdint> on Windows which was not available before > MSVC 10. > > 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. 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. Bill. > > Brian > > > > > > > > > Bill. > > > -- > 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. > -- 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.
