Micah Cowan <[email protected]> writes: > If it didn't support stdint.h, obviously this patch would not have > worked. The point is that the code _doesn't_ check for stdint; it > checks for C99.
You're right; the idea was to either get uintptr_t through C99 or define it ourselves. But, as you said, stdint.h can exist as an extension and be included by another header, in which case it redefines uintptr_t, which fails. This could be fixed by using another type, such as: #if ...C99... # include <stdint.h> // get uintptr_t from C99 typedef uintptr_t hash_uintptr_t; #else typedef unsigned long hash_uintptr_t; // assume pointer fits in long #endif >>> There's the other possibility, of trying to avoid casting a pointer >>> to an integer type in the first place. I haven't looked much at this >>> code, though, and honestly probably won't any time real soon. >> >> The code casts pointer to integer in two places: the first is to >> implement an "invalid pointer" constant, and the second to hash a >> pointer value by identity. I'm not sure if you can eliminate >> uintptr_t from those places without essentially reinventing it. > > Where do we need to hash pointers, instead of string values? In transport_map. Even if Wget didn't use it, it would be a useful thing to support in a hash table library, at least in #ifndef WGET. > What about iterating over the pointer value with a (char *) for > sizeof (pointer-type) bytes, to generate an appropriate hash (IOW, > treat it the same way strings are). > > Obviously this is (mildly) slower than using an int value directly. That doesn't seem like the right thing to do, at least not for this reason. Also, you don't propose an alternative for "invalid pointer value", which also uses uintptr_t. Another option altogether would be to switch to a hash table implementation from gnulib or so. When I wrote hash.c, such hash table implementations were scarce, and I couldn't find a single one that was both simple and satisfactory. I imagine things have changed since then.
