"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > On Wed, Jan 29, 2014 at 09:52:45PM +0100, David Kastrup wrote: >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> > Hmm... if you were to implement a set of pointers in such a way that >> > you can cheaply tell if an unknown pointer belongs to that set, you >> > would use a hashtable, keyed with something that is derived from the >> > value of the pointer casted to uintptr_t, I would think. >> >> The types intptr_t and uintptr_t are optional in ISO/IEC 9899:1999 >> (C99). So it would seem that I'd be covering fewer cases rather than >> more in that manner. > > I think we already use uintptr_t in the codebase, and if it's not > present, we typedef it to unsigned long. So I think it should be fine > (and well-defined) if instead of doing > > void *p, *q; > ... > if (p < q) > ... > > you do: > > void *p, *q; > ... > if ((uintptr_t)p < (uintptr_t)q) > ... > > Then on those systems where the compiler has some bizarre undefined > behavior checking, the code will work. On systems that don't have > uintptr_t, the compiler is probably not smart enough to perform such a > check anyway. The use case is actually sorting a list such that entries pointing to the same malloced "origin" data structure are in adjacent list positions. At list intptr_t seems used plentifully in Git. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html