This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about building hash values from pointers
- From: Andrew Haley <aph at redhat dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Richard Guenther <richard dot guenther at gmail dot com>, Kai Tietz <Kai dot Tietz at onevision dot com>, gcc at gcc dot gnu dot org
- Date: Sun, 01 Jun 2008 11:36:29 +0100
- Subject: Re: Question about building hash values from pointers
- References: <OF32DEF3A4.FD0884CD-ONC1257459.00307EA6-C1257459.003132A3@onevision.de> <84fc9c000805300259l5eadc01eh9f1a02d826ab990f@mail.gmail.com> <483FD1F5.7020407@redhat.com> <m3abi7x4s8.fsf@google.com>
Ian Lance Taylor wrote:
> Andrew Haley <aph@redhat.com> writes:
>
>> Richard Guenther wrote:
>>> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <Kai.Tietz@onevision.com> wrote:
>>>> Hi,
>>>>
>>>> as I noticed, most hash value calculations are trying to use pointer
>>>> values for building the value and assume that a long/unsigned long scalar
>>>> is wide enough for a pointer. This is at least for w64 target not true. So
>>>> I want to know, if it would be good to introduce an gcc specific type for
>>>> those kind of casts, or to use ssize_t/size_t.?
>>> it's uintptr_t which should be used, if only as an intermediate cast -
>>> (unsigned long)(uintptr_t)ptr.
>> That's not possible because, IIRC, gcc must compile on C90 systems.
>
> We can just test for it with autoconf and typedef it if we don't have
> it. We can figure out what to typedef it to by comparing the sizeof
> void* to the sizeof the integer types--we already gather these sizes
> in the configure script anyhow, and use them in hwint.h.
Given that all this seems to be about is avoiding warning messages on
some extremely unlikely architectures on which gcc may not run, I have
to question the sens of such heavyweight measures. Why not simply use
size_t? It would be adequate on every architecture anyone here knows
about.
Andrew.