Including <limits.h> in gmp-impl.h
nisse at lysator.liu.se
Thu Jan 2 18:41:18 UTC 2014
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)
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.
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel