Hi Bill, Brian,

Sorry, I was of the radar for a bit. Yes, Bill, you understood correctly
what I meant.

On 8 August 2013 15:43, Bill Hart <goodwillh...@googlemail.com> wrote:

>
>
>
> On 8 August 2013 12:53, Brian Gladman <b...@gladman.plus.com> wrote:
>
>> On 08/08/2013 11:38, degski wrote:
>>
>> > "It is possible that 'long long' types and 'intmax_t' types are not
>> > distinguishable so it sees two overloads that it cannot disambiguate."
>> >
>> > This is the problem:
>> >
>> > typedef long long intmax_t;
>> > typedef unsigned long long uintmax_t;
>> >
>> > Is what going on on VS2012 c++11, x64.
>>
>> Yes, these are long long types on Windows x64
>>
>> > signed long long int seems to be the same as long long, the same for the
>> > unsigned versions.
>>
>> I understand that 'signed long long' is the same type as 'long long' but
>> are you saying that 'unsigned long long' is also the same type as
>> 'long long'?  That doesn't seem right to me.
>>
>
> He just means unsigned long long is the same as unsigned long long int, I
> guess.
>
>
Yes, just being a bit terse, sorry.

> Certainly the signed and unsigned versions are different.
>
>
>>
>> > The GMP signatures for the first two functions are:
>> >
>> > void *mpz_set_ui* (mpz_t rop, unsigned long int op)
>> > void *mpz_set_si* (mpz_t rop, signed long int op)
>>
>> MPIR defines these as:
>>
>>   void mpz_set_ui(mpz_ptr, mpir_ui);
>>   void mpz_set_si(mpz_ptr, mpir_si);
>>
>> where mpir_ui/si map to long types everywhere except on Windows x64
>> where they map to long long types.
>>
>> > So it comes down to the LP64 vs the LLP64, (long is 32-bit on Win and
>> > 64-bit on Lin) I guess some macro's to properly deal with the windows
>> case
>> > and the bitness of the build are in order.
>>
>> I don't understand this - can you elaborate please.
>>
>
> He's just referring to the fact that on 64 bit linux long is 64 bits,
> whereas on Windows it's 32 bits. So he's recommending that we fix the
> problem with some macros which distinguish whether we are on Windows or
> not, and whether the machine is 32 bits or 64 bits.
>
>

The types I mentioned is what VS2012 defines them as, you can see that by
hovering over the  types, f.e. intmax_t, you can than see the definitions,
it's as Isaid earlier.


>
>
I guess we were already doing this, but we got it wrong somewhere.
> Specifically, you cannot overload a function for intmax_t and long long
> because they are the same type.
>
>
Yes, that's not allowed in C++.

>
>
On 64 bit linux it is worse because intmax_t, long and long long are
> effectively all the same type (not actually sure long and long long are the
> same on 64 bit linux, haven't checked, but it's feasible, as they are both
> 64 bits).
>
> Bill.
>
>
>>
>>    Brian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mpir-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mpir-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to mpir-devel@googlegroups.com.
>> Visit this group at http://groups.google.com/group/mpir-devel.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
Sign the petition:
https://optin.stopwatching.us/<https://optin.stopwatching.us/>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to