[Kde-bindings] Fwd: Qyoto/Kimono: A 64 bit unsafe function, build trouble on Debian unstable

[Arno Rehn]

Am Montag, 28. Mai 2007 schrieb Richard Dale:
> On Monday 28 May 2007, Arno Rehn wrote:
> > Am Montag, 28. Mai 2007 schrieb Richard Dale:
> > > On Sunday 27 May 2007, Arno Rehn wrote:
> > > >                 qint64 key = (qint64) o->ptr;
> > > >                 return (int) ((key >> (8 * sizeof(int) - 1)) ^ key);
> > >
> > > Well I tried a quick experiment, and I'm not sure the result has the
> > > same bytes as the original 'o->ptr' when there are 32 bits to a pointer
> > > and for ints:
> >
> > Well, is that necessary at all? We just need a unique number, it doesn't
> > have to be the pointer... And the returned value is unique since it is
> > 'generated' from the pointer, isn't it?
>
> It doesn't have to be a unique number, the addresses just need to be evenly
> spread. But if we take the bottom 32 bits of a 32 bit address we can be
> certain that it is a unique number. I would like it to work the same way as
> the original Qt QHash code which looks like this:
>
> inline uint qHash(quint64 key)
> {
>     if (sizeof(quint64) > sizeof(uint)) {
>         return uint((key >> (8 * sizeof(uint) - 1)) ^ key);
>     } else {
>         return uint(key);
>     }
> }
>
> I don't why 'uint(key)' compiles ok, but '(uint) key' doesn't. Because we
> want to return a signed int as a result I think it's best to '&' with
> 0xfffffffff to get the bottom 32 bits of the pointer (ie all of it on a 32
> bit machine), as it will avoid any possible problems with unexpected sign
> extension going on during the conversion.
Yes, that's right. It's probably the better solution.

-- 
Arno Rehn
arno at arnorehn.de