Re: C standard compliance?

[David Kastrup <dak@gnu.org>]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> 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