Bug: "unsigned long" != "size_t" in tal-notreent.c
librik@panix.com
librik at panix.com
Mon Apr 3 18:56:31 CEST 2006
Here's another small fix for tal-notreent.c (and gmp-impl.h).
Several function prototypes and local variables in GMP 4.2's
tal-notreent.c use the type "unsigned long" to hold the size
of a range of memory. This is often acceptable, but it's not
guaranteed to be sufficiently large on 64-bit architectures.
Luckily, ANSI C provides a type "size_t" which is required to
be wide enough to hold a the size of range of memory, so this
is easy to fix.
--- tal-notreent.c.sizet 2006-04-01 14:26:27.286100800 -0600
+++ tal-notreent.c 2006-03-14 09:57:54.000000000 -0600
@@ -34,6 +34,6 @@
-static size_t max_total_allocation = 0;
-static size_t current_total_allocation = 0;
+static unsigned long max_total_allocation = 0;
+static unsigned long current_total_allocation = 0;
static tmp_stack xxx = {&xxx, &xxx, 0};
@@ -47,5 +47,5 @@
through the TMP_ALLOC macro, which takes care of rounding/alignment. */
void *
-__gmp_tmp_alloc (size_t size)
+__gmp_tmp_alloc (unsigned long size)
{
void *that;
@@ -58,6 +58,6 @@
void *chunk;
tmp_stack *header;
- size_t chunk_size;
- size_t now;
+ unsigned long chunk_size;
+ unsigned long now;
/* Allocate a chunk that makes the total current allocation somewhat
--- gmp-impl.h.sizet 2006-04-01 14:27:53.339840000 -0600
+++ gmp-impl.h 2006-03-23 11:20:12.000000000 -0600
@@ -358,5 +358,5 @@
void *alloc_point;
};
-void *__gmp_tmp_alloc _PROTO ((size_t)) ATTRIBUTE_MALLOC;
+void *__gmp_tmp_alloc _PROTO ((unsigned long)) ATTRIBUTE_MALLOC;
void __gmp_tmp_mark _PROTO ((struct tmp_marker *));
void __gmp_tmp_free _PROTO ((struct tmp_marker *));
@@ -368,5 +368,5 @@
#define TMP_BALLOC(n) TMP_ALLOC(n)
#define TMP_ALLOC(n) \
- __gmp_tmp_alloc (ROUND_UP_MULTIPLE ((size_t) (n), __TMP_ALIGN))
+ __gmp_tmp_alloc (ROUND_UP_MULTIPLE ((unsigned long) (n), __TMP_ALIGN))
#define TMP_SFREE TMP_FREE
#define TMP_FREE __gmp_tmp_free (&__tmp_marker)
The rules I've learned from reading comp.lang.c are that,
in a portable C program, you should only use the keyword
"long int" if you need a type that is:
* guaranteed to be at least 32 bits wide, or
* guaranteed to be wider than "short int", or
* required to match a system call interface that uses "long".
Most comp.lang.c rules are pretty ridiculous, but I think this
is a sensible one. It helps avoid the mistake of treating
"long" integers as equivalent to natural machine words (32 bits
or 64 bits).
- David Librik
librik at panix.com
More information about the gmp-bugs
mailing list