Marc Glisse <marc.gli...@inria.fr> writes: > I'll also push a patch handling the fact that the standard SHRT_MAX > and others don't have type short but int.
Can you explain what the problem is? I noticed this change, --- a/gmp-h.in Thu Jan 02 12:28:21 2014 +0100 +++ b/gmp-h.in Thu Jan 02 13:25:31 2014 +0100 @@ -437,10 +437,10 @@ #define __GMP_MAX(h,i) ((h) > (i) ? (h) : (i)) /* __GMP_USHRT_MAX is not "~ (unsigned short) 0" because short is promoted - to int by "~". */ + to int by "~". It still needs to have the promoted type. */ #define __GMP_UINT_MAX (~ (unsigned) 0) #define __GMP_ULONG_MAX (~ (unsigned long) 0) -#define __GMP_USHRT_MAX ((unsigned short) ~0) +#define __GMP_USHRT_MAX (0 + (unsigned short) ~0) Questions: 1. Why should it be of type int? Which problems are caused by having it as unsigned short? 2. If int is desired, I think it's a bit clearer with an explicit cast, #define __GMP_USHRT_MAX ((int) (unsigned short) ~0) But, unconditionally defining it as int also seems unportable. A C implementation may define both short and int to be 32 bits, right? Then the maximum unsigned short doesn't fit in a signed int. While it would always fit in an *unsigned* int. Is that what the "0 + " promotion thing is intended to do; you know the spec a better than me, but you'd get unsigned int if short and int are of the same size, and signed int if it's of larger size than short? I miss a comment spelling out which type really is intended, and why. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
