[Kde-bindings] KDE/kdebindings/csharp/qyoto

Arno Rehn arno at arnorehn.de
Mon May 28 18:21:34 UTC 2007


Am Montag, 28. Mai 2007 schrieb Richard Dale:
> On Monday 28 May 2007, Arno Rehn wrote:
> > Am Montag, 28. Mai 2007 schrieb Richard Dale:
> > > SVN commit 669114 by rdale:
> > >
> > > * Attempted to add a QyotoHash function that will compile on 64 bit
> > >   machines
> >
> > Hmm, that doesn't even compile on my 32 bit machine.
> >
> > error: invalid operands of types 'void*' and 'unsigned int' to
> > binary 'operator&'
> >
> > When we change it like this:
> >
> > return (int) (((qint64) o->ptr) & 0xFFFFFFFF);
> >
> > it works, on both 32 bit and 64 bit.
> > In this case we wouldn't even need the "& 0xFFFFFFFF" thing, I think. We
> > should be able to just cast first to an qint64, which would make the
> > compiler happy, and then to a normal int, which would suit our needs. As
> > this is never called on a 64 bit machine, it wouldn't cause any data
> > loss. So
> >
> > return (int) (qint64) o->ptr;
>
> Well I wasn't sure about the sign extension rules for that sort of thing.
> For instance, I'm pretty sure this would work:
> return (uint) (quint64) o->ptr;
>
> But with
> return (int) (qint64) o->ptr;
>
> I wondered if the int happened to be negative, whether you still end up
> with the original bit pattern as in the 'o->ptr' if you go via a 'qint64'
> if you don't have the '& 0xFFFFFFFF' part. It might be ok, and without
> that, and so I would change it to whichever you prefer, as the main thing
> is that it compiles rather than fills up a hash table perfectly for now.
In the tests I've done it all looked good with signed ints and qint64s, so I'd 
do it with (int) (qint64) o->ptr. When someone encounters an error, we can 
still fix it.

-- 
Arno Rehn
arno at arnorehn.de



More information about the Kde-bindings mailing list