Re: C standard compliance?
- From
David Kastrup <dak@gnu.org>
- Date
- Jan 30, 2014, 00:02 UTC
- Message-ID
- <877g9i5oc3.fsf@fencepost.gnu.org>
- In-Reply-To
- <20140129233321.GC91854@vauxhall.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 31 quoted lines
> On Wed, Jan 29, 2014 at 09:52:45PM +0100, David Kastrup wrote: >> Junio C Hamano <gitster@pobox.com> 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