On 12 October 2012 22:37, Brian Gladman <b...@gladman.plus.com> wrote:
> -----Original Message----- From: Bill Hart
> Sent: Friday, October 12, 2012 10:29 PM
>
> To: mpir-devel@googlegroups.com
> Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released
>
> On 12 October 2012 22:27, Brian Gladman <b...@gladman.plus.com> wrote:
>>
>> -----Original Message----- From: Bill Hart
>> Sent: Friday, October 12, 2012 10:20 PM
>>
>> To: mpir-devel@googlegroups.com
>> Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released
>>
>> 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.
>>
>> ==============================
>> When an MPIR user includes stdint.h or cstdint in _their_ code before they
>> include mpirxx.h, the types in question will then be available to them
>> ==============================
>
>
> OK, but we can't test that this works.
>
> ================================
> If we want a test for this we can add one to the test suite and only invoke
> it on systems that have stdint.h.
>
> This would be easy on Windows but I accept that this may not be on *nix.

This is *not* possible on linux. The presence or otherwise of stdint.h
is not a feature of the compiler (before c99) but a feature of the
libc. There simply isn't a way to do compile time testing for its
existence. You absolutely have to use the HAVE_STDINT_H flag provided
by configure in config.h.

For that reason, we can't get around using config.h in our tests.

>
> Do we want to get rid of all these uses of config.h in the tests?
>
> cxx\t-assign.cc(22):#include "config.h"
> cxx\t-binary.cc(22):#include "config.h"
> cxx\t-constr.cc(22):#include "config.h"
> cxx\t-misc.cc(29):#include "config.h"
> cxx\t-ops.cc(22):#include "config.h"
> cxx\t-prec.cc(22):#include "config.h"
> cxx\t-ternary.cc(22):#include "config.h"
> cxx\t-unary.cc(22):#include "config.h"
> misc\t-locale.c(26):#include "config.h"
> misc\t-printf.c(30):#include "config.h"
> misc\t-scanf.c(34):#include "config.h"
> mpf\t-inp_str.c(22):#include "config.h"
> mpn\t-get_d.c(28):#include "config.h"
> mpq\t-aors.c(22):#include "config.h"
> mpq\t-inp_str.c(22):#include "config.h"
> mpz\t-inp_str.c(22):#include "config.h"
> mpz\io.c(22):#include "config.h"
> mpz\t-io_raw.c(22):#include "config.h"
> 4\Release\gmp-impl.h(112):#include "config.h"
> vc10\getopt.c(34):# include <config.h>
> misc.c(22):#include "config.h"
> mpn\t-invert.c(30):#include "config.h"
> mpz\t-get_sx.c(26):#include "config.h"
> mpz\t-set_sx.c(25):#include "config.h"
> mpz\t-get_ux.c(25):#include "config.h"
> mpz\t-set_ux.c(25):#include "config.h"

It won't work on linux if we do, for the above reason. The danger of
course is that the tests could rely on things that are not available
to the user.

But this seems unavoidable.

By the way, I just made <climits> included unconditionally. We need
this to test for LLONG_MAX on some linux systems. Fortunately this is
a standard header. It doesn't cause a problem any more because we do
not need INTMAX_MAX on linux.

This change shouldn't affect the Windows builds, and I just tested
that it works on ia64 and x86_64.

Two machines down, only a couple of dozen to go.

The biggest problems on x86_64 and ia64 now are the format specifiers
for intmax_t and size_t. But both of these are another can of worms.
To get them correct on linux we need to use the macros leif specified.
But these aren't available on some linux systems and on MSVC because
they only partly implements stdint.h as they are not fully C99
compliant.

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.

Reply via email to