Including <limits.h> in gmp-impl.h

[Niels Möller]

Marc Glisse <marc.glisse at 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.