Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Vincent Lefevre]

On 2020-06-09 10:21:31 +0200, Marc Glisse wrote:
> On Tue, 9 Jun 2020, Niels Möller wrote:
> 
> > Marc Glisse  writes:
> > 
> > > On Sat, 6 Jun 2020, Mihai Preda wrote:
> > > 
> > > > I would rather suggest to support intmax_t and uintmax_t.
> > > 
> > > That's one possibility for C (and C++, although it is a bit more
> > > painful there), but not one that everyone agrees with. I think the
> > > majority in standard committees believes that those 2 types were a
> > > mistake,
> > 
> > Any reference for such discussions?
> 
> No, I didn't take notes, and not all discussions are public. A quick search
> gives one paper presented to the C committee on the topic
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2303.pdf

The proposed change is worse. For instance, this would mean that
mp_limb_t could be larger than uintmax_t. This is an issue when
doing computations mixing various integer types from libraries, for
which one does not know their sizes. Or perhaps typeof could be the
solution, together with the ability to select the signedness of an
arbitrary integer type.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Marc Glisse]

On Tue, 9 Jun 2020, Niels Möller wrote:


Marc Glisse  writes:


On Sat, 6 Jun 2020, Mihai Preda wrote:


I would rather suggest to support intmax_t and uintmax_t.


That's one possibility for C (and C++, although it is a bit more
painful there), but not one that everyone agrees with. I think the
majority in standard committees believes that those 2 types were a
mistake,


Any reference for such discussions?


No, I didn't take notes, and not all discussions are public. A quick 
search gives one paper presented to the C committee on the topic 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2303.pdf



in particular because they are 64 bits on platforms that now
have a 128 bit type, but cannot change intmax_t as that would break
the ABI.


Isn't that exactly what happened to "long", long ago? Just like
intmax_t, long was supposed to be the platform's largest supported
integer type.


At least they had the foresight to call it "long" and not "longest".

--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Hans Åberg]

> On 6 Jun 2020, at 06:28, Mihai Preda  wrote:
> 
> At this point the C++ compiler on windows (where long is 32-bit)
> reports errors, see at the end. The problem is that the set of
> constructors does not include one taking a 64-bit integer:
> 
> #define __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS\
>  __gmp_expr(signed char c) { init_si(c); }\
>  __gmp_expr(unsigned char c) { init_ui(c); }\
>  __gmp_expr(signed int i) { init_si(i); }\
>  __gmp_expr(unsigned int i) { init_ui(i); }\
>  __gmp_expr(signed short int s) { init_si(s); }\
>  __gmp_expr(unsigned short int s) { init_ui(s); }\
>  __gmp_expr(signed long int l) { init_si(l); }\
>  __gmp_expr(unsigned long int l) { init_ui(l); }\
>  __gmp_expr(float f) { init_d(f); }\
>  __gmp_expr(double d) { init_d(d); }
> 
> Among all in the list above, none takes a uint64_t or int64_t.

Those types are just typedefs to the appropriate C types [1], and with those 
compilers one would have to use [unsigned/signed] long long [2], which is not 
on the list. So it would suffice adding those, it would seem.

1. https://en.cppreference.com/w/cpp/types/integer
2. https://en.cppreference.com/w/cpp/language/types


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Niels Möller]

Marc Glisse  writes:

> On Sat, 6 Jun 2020, Mihai Preda wrote:
>
>> I would rather suggest to support intmax_t and uintmax_t.
>
> That's one possibility for C (and C++, although it is a bit more
> painful there), but not one that everyone agrees with. I think the
> majority in standard committees believes that those 2 types were a
> mistake,

Any reference for such discussions?

> in particular because they are 64 bits on platforms that now
> have a 128 bit type, but cannot change intmax_t as that would break
> the ABI.

Isn't that exactly what happened to "long", long ago? Just like
intmax_t, long was supposed to be the platform's largest supported
integer type. Maybe we'll see a "long intmax_t" type when 128-bit types
become more established ;-)

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Marc Glisse]

On Mon, 8 Jun 2020, Vincent Lefevre wrote:


Couldn't the C interface *optionally* support more than C89?


I think the policy has been to have one uniform interface, and requiring 
C99 for GMP is likely to happen. I am generally in favor of optional 
support for __int128, which wouldn't be available everywhere, but more 
people need convincing ;-)



But isn't the support for 128-bit integers incomplete (i.e. not all
operations required by ISO C for an integer type are implemented)?


I believe there is a chicken and egg problem. If they implement 
everything, they have to bump intmax_t.



Anyway you don't introduce a new large builtin integer type everyday.
ABI breakages are annoying, but when they are rare, this could be
acceptable. Moreover, I suspect that very few libraries/applications
would be affected by a change of (u)intmax_t. And these are those
that would benefit from such a change.


We don't get to pick what intmax_t refers to. I am also in favor of 
breaking ABIs once in a while to fix some mistakes or modernize some 
things, but that's not how redhat (for instance) sees things.


--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Vincent Lefevre]

On 2020-06-08 22:32:25 +0200, Marc Glisse wrote:
> On Sat, 6 Jun 2020, Mihai Preda wrote:
> 
> > At this point the C++ compiler on windows (where long is 32-bit)
> > reports errors, see at the end. The problem is that the set of
> > constructors does not include one taking a 64-bit integer:
> 
> The issue is that:
> 1) the C++ interface follows the C interface
> 2) the C interface is still C89 (no long long)
> 3) Microsoft chose an absurd ABI for win64 (32bit long)
> 
> 3) is unlikely to change, we could change 1) but I'd rather not. The most
> likely evolution is about 2), at some indeterminate point in the future
> (hopefully not too far).

Couldn't the C interface *optionally* support more than C89?

> On Sat, 6 Jun 2020, Vincent Lefevre wrote:
> 
> > There's the same issue with 32-bit architectures, whatever the OS.
> 
> Indeed. And many users would also appreciate interoperability with
> int128_t (or whatever name it uses on their platform).

But isn't the support for 128-bit integers incomplete (i.e. not all
operations required by ISO C for an integer type are implemented)?

> > I would rather suggest to support intmax_t and uintmax_t.
> 
> That's one possibility for C (and C++, although it is a bit more painful
> there), but not one that everyone agrees with. I think the majority in
> standard committees believes that those 2 types were a mistake, in
> particular because they are 64 bits on platforms that now have a 128 bit
> type, but cannot change intmax_t as that would break the ABI.

I think that the first reason is that the support for 128-bit integers
is incomplete.

> Still, it isn't a bad choice for a large builtin integer type.

Anyway you don't introduce a new large builtin integer type everyday.
ABI breakages are annoying, but when they are rare, this could be
acceptable. Moreover, I suspect that very few libraries/applications
would be affected by a change of (u)intmax_t. And these are those
that would benefit from such a change.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Marc Glisse]

On Sat, 6 Jun 2020, Mihai Preda wrote:


At this point the C++ compiler on windows (where long is 32-bit)
reports errors, see at the end. The problem is that the set of
constructors does not include one taking a 64-bit integer:


The issue is that:
1) the C++ interface follows the C interface
2) the C interface is still C89 (no long long)
3) Microsoft chose an absurd ABI for win64 (32bit long)

3) is unlikely to change, we could change 1) but I'd rather not. The most 
likely evolution is about 2), at some indeterminate point in the future 
(hopefully not too far).



The fix could consist in having these constructors take int64_t
instead of long int, etc. I.e. take explicitly-sized typed instead of
the "long" which is variable-size.


Well, if the function accepts int64_t, it needs to be taught how to handle 
it, the fix isn't that localized.



On Sat, 6 Jun 2020, Vincent Lefevre wrote:


There's the same issue with 32-bit architectures, whatever the OS.


Indeed. And many users would also appreciate interoperability with 
int128_t (or whatever name it uses on their platform).



I would rather suggest to support intmax_t and uintmax_t.


That's one possibility for C (and C++, although it is a bit more painful 
there), but not one that everyone agrees with. I think the majority in 
standard committees believes that those 2 types were a mistake, in 
particular because they are 64 bits on platforms that now have a 128 bit 
type, but cannot change intmax_t as that would break the ABI. Still, it 
isn't a bad choice for a large builtin integer type.


--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Vincent Lefevre]

On 2020-06-06 14:28:21 +1000, Mihai Preda wrote:
> I'm using libgmp-dev 6.1.2 on Ubuntu myself, but the bug report
> concerns an unspecified version of GMP on Windows. I have reasons to
> suspect the bug is valid for the most recent GMP. Clear cause analysis
> and proposed solution is included.
> 
> I'm not a Windows user myself. I develop an open-source app that users
> are compiling, among others, on Windows with mingw or other c++
> compilers on windows. A common habit of these c++ compilers on windows
> is to have 32-bit long.

There's the same issue with 32-bit architectures, whatever the OS.

> In my app I construct a mpz_class from a 64-bit unsigned integer, like this:
> uint64_t h = ...;
> mpz_class{h};
> 
> At this point the C++ compiler on windows (where long is 32-bit)
> reports errors, see at the end. The problem is that the set of
> constructors does not include one taking a 64-bit integer:
> 
> #define __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS\
>   __gmp_expr(signed char c) { init_si(c); }\
>   __gmp_expr(unsigned char c) { init_ui(c); }\
>   __gmp_expr(signed int i) { init_si(i); }\
>   __gmp_expr(unsigned int i) { init_ui(i); }\
>   __gmp_expr(signed short int s) { init_si(s); }\
>   __gmp_expr(unsigned short int s) { init_ui(s); }\
>   __gmp_expr(signed long int l) { init_si(l); }\
>   __gmp_expr(unsigned long int l) { init_ui(l); }\
>   __gmp_expr(float f) { init_d(f); }\
>   __gmp_expr(double d) { init_d(d); }
> 
> Among all in the list above, none takes a uint64_t or int64_t.
> 
> The fix could consist in having these constructors take int64_t
> instead of long int, etc. I.e. take explicitly-sized typed instead of
> the "long" which is variable-size.

I would rather suggest to support intmax_t and uintmax_t.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs