-----Original Message-----
From: Bill Hart
Sent: Friday, October 12, 2012 10:05 PM
To: [email protected]
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
========================================
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.
Brian
--
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.
