From: David Kastrup <dak@gnu•org>
To: git@vger•kernel.org
Subject: Re: C standard compliance?
Date: Thu, 30 Jan 2014 01:02:20 +0100 [thread overview]
Message-ID: <877g9i5oc3.fsf@fencepost.gnu.org> (raw)
In-Reply-To: 20140129233321.GC91854@vauxhall.crustytoothpaste.net
"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
prev parent reply other threads:[~2014-01-30 0:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 20:33 C standard compliance? David Kastrup
2014-01-29 20:42 ` Junio C Hamano
2014-01-29 20:52 ` David Kastrup
2014-01-29 23:00 ` Philip Oakley
2014-01-29 23:33 ` brian m. carlson
2014-01-30 0:02 ` David Kastrup [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877g9i5oc3.fsf@fencepost.gnu.org \
--to=dak@gnu$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox