On 2020-06-09 10:21:31 +0200, Marc Glisse wrote: > On Tue, 9 Jun 2020, Niels Möller wrote: > > > Marc Glisse <[email protected]> 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 <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) _______________________________________________ gmp-bugs mailing list [email protected] https://gmplib.org/mailman/listinfo/gmp-bugs
