Nonportable code in C++ support

Hi,

apparently there's some non-portable code in C++ support and
with
non-portable I mean building breaks on anything but 32 bit
platforms.

The problem is hashFromFunction in typerepository.cpp, line
665 and
following. There a pointer is casted to int, which obviously
won't work
on 64 bit where this is a long.

The error that was reported is that the cast to int looses
precision,
however I don't see a way to preserve the precision as we
need to get an
int out of the function. Ideas?

Oh and apparently s/int/long in 265, 266 and 267 fixes the
build issue.

Andreas

-- 
Your love life will be... interesting.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 13 February 2008 00:21:26 Andreas Pakulat
wrote:
> Hi,
>
> apparently there's some non-portable code in C++
support and with
> non-portable I mean building breaks on anything but 32
bit platforms.
>
> The problem is hashFromFunction in typerepository.cpp,
line 665 and
> following. There a pointer is casted to int, which
obviously won't work
> on 64 bit where this is a long.
>
> The error that was reported is that the cast to int
looses precision,
> however I don't see a way to preserve the precision as
we need to get an
> int out of the function. Ideas?
>
> Oh and apparently s/int/long in 265, 266 and 267 fixes
the build issue.
>
> Andreas

Hi! The code compiles just fine on my 64 bit machine(there
was an issue some 
time, but that was fixed). Where does the build fail?


Since the int does not need to 100% represent the pointer,
but rather is just 
used as an approximate hash-value, the conversion should not
be problematic.

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 13.02.08 00:36:48, David Nolden wrote:
> On Wednesday 13 February 2008 00:21:26 Andreas Pakulat
wrote:
> > Hi,
> >
> > apparently there's some non-portable code in C++
support and with
> > non-portable I mean building breaks on anything
but 32 bit platforms.
> >
> > The problem is hashFromFunction in
typerepository.cpp, line 665 and
> > following. There a pointer is casted to int, which
obviously won't work
> > on 64 bit where this is a long.
> >
> > The error that was reported is that the cast to
int looses precision,
> > however I don't see a way to preserve the
precision as we need to get an
> > int out of the function. Ideas?
> >
> > Oh and apparently s/int/long in 265, 266 and 267
fixes the build issue.
> >
> > Andreas
> 
> Hi! The code compiles just fine on my 64 bit
machine(there was an issue some 
> time, but that was fixed). Where does the build fail?

Somebody popped up in #kdevelop and had an error saying that
the cast
looses precision. He was on 64 bit and changing from int to
long fixed
the build for him.

The error was for line 265 and 266.

I'm not sure wether precision-loosing is actually an error
or just a
warning and he somehow had -Werror set (or maybe -pedantic,
aaah gcc has
soooo many options)...

> Since the int does not need to 100% represent the
pointer, but rather is just 
> used as an approximate hash-value, the conversion
should not be problematic.

Ok, then I think casting to long is better, it doesn't break
on 32 Bit
and obviously fixes some 64 Bit builds.

Andreas

-- 
You will be honored for contributing your time and skill to
a worthy cause.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 13 February 2008 10:11:48 Andreas Pakulat
wrote:
> Ok, then I think casting to long is better, it doesn't
break on 32 Bit
> and obviously fixes some 64 Bit builds.

But since the hash-values are always 32 bit, won"t you
then get a warning when 
casting long -> uint?  Of course,
any way of removing the warning is fine.

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> But since the hash-values are always 32 bit, won"t
you then
> get a warning when
> casting long -> uint?  Of course,
any way of removing the
> warning is fine.

int hash = (int)((size_t)ptr + [whatever]);

Let's not forget, longs are 4 bytes on 64 bit Windows.

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 13 February 2008, Kris Wong wrote:
> > But since the hash-values are always 32 bit,
won"t you then
> > get a warning when
> > casting long -> uint?  Of course,
any way of removing the
> > warning is fine.
>
> int hash = (int)((size_t)ptr + [whatever]);
>
> Let's not forget, longs are 4 bytes on 64 bit Windows.

Wouldn't this work better? It should be portable, too,
although
it has a benign warning on 32 bits.

void * ptr;
unsigned long lptr = (unsigned long)ptr;
lptr = (lptr >> 32) ^ (lptr & 0xffffffff);
int hash = (int)lptr;

The hash value on 32 bit platforms should be simply the
value of the
pointer, while on 64 bits it will be the upper and lower
halves xor-ed
together.

Cheers, Kuba

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 13 February 2008 17:13:16 Kuba Ober wrote:
> On Wednesday 13 February 2008, Kris Wong wrote:
> > > But since the hash-values are always 32 bit,
won"t you then
> > > get a warning when
> > > casting long -> uint?  Of course,
any way of removing the
> > > warning is fine.
> >
> > int hash = (int)((size_t)ptr + [whatever]);
> >
> > Let's not forget, longs are 4 bytes on 64 bit
Windows.
>
> Wouldn't this work better? It should be portable, too,
although
> it has a benign warning on 32 bits.
>
> void * ptr;
> unsigned long lptr = (unsigned long)ptr;
> lptr = (lptr >> 32) ^ (lptr & 0xffffffff);
> int hash = (int)lptr;
>
> The hash value on 32 bit platforms should be simply the
value of the
> pointer, while on 64 bits it will be the upper and
lower halves xor-ed
> together.

You mean, in the case you get many hash collisions across
4Gb of memory? 
Personally, I'd go with the code from the c++ standard
library:

return reinterpret_cast<std::size_t>(p);

except that the cast would be to int  Simple,
fast, and very likely to 
return different values for different pointers, even modulo
some number 
2^n-1.


-- 
regards, Esben

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 13 February 2008 17:13:16 Kuba Ober wrote:
> On Wednesday 13 February 2008, Kris Wong wrote:
> > > But since the hash-values are always 32 bit,
won"t you then
> > > get a warning when
> > > casting long -> uint?  Of course,
any way of removing the
> > > warning is fine.
> >
> > int hash = (int)((size_t)ptr + [whatever]);
> >
> > Let's not forget, longs are 4 bytes on 64 bit
Windows.
>
> Wouldn't this work better? It should be portable, too,
although
> it has a benign warning on 32 bits.
>
> void * ptr;
> unsigned long lptr = (unsigned long)ptr;
> lptr = (lptr >> 32) ^ (lptr & 0xffffffff);
> int hash = (int)lptr;
>
> The hash value on 32 bit platforms should be simply the
value of the
> pointer, while on 64 bits it will be the upper and
lower halves xor-ed
> together.

You mean, in the case you get many hash collisions across
4Gb of memory? 
Personally, I'd go with the code from the c++ standard
library:

return reinterpret_cast<std::size_t>(p);

except that the cast would be to int  Simple,
fast, and very likely to 
return different values for different pointers, even modulo
some number 
2^n-1.


-- 
regards, Esben

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 13 February 2008, Esben Mose Hansen wrote:
> On Wednesday 13 February 2008 17:13:16 Kuba Ober
wrote:
> > On Wednesday 13 February 2008, Kris Wong wrote:
> > > > But since the hash-values are always 32
bit, won"t you then
> > > > get a warning when
> > > > casting long -> uint?  Of course,
any way of removing the
> > > > warning is fine.
> > >
> > > int hash = (int)((size_t)ptr + [whatever]);
> > >
> > > Let's not forget, longs are 4 bytes on 64 bit
Windows.
> >
> > Wouldn't this work better? It should be portable,
too, although
> > it has a benign warning on 32 bits.
> >
> > void * ptr;
> > unsigned long lptr = (unsigned long)ptr;
> > lptr = (lptr >> 32) ^ (lptr &
0xffffffff);
> > int hash = (int)lptr;
> >
> > The hash value on 32 bit platforms should be
simply the value of the
> > pointer, while on 64 bits it will be the upper and
lower halves xor-ed
> > together.
>
> You mean, in the case you get many hash collisions
across 4Gb of memory?

I don't know how the memory is organized on 64 bit machines,
but presumably 
they have virtual memory too, and one then presumes that say
stack, heap and 
dynamic libraries can be possibly spread all over the
petabytes. Just like on 
some 32 bit platforms - heap, stack and library code are
nowhere near one 
another, there are huge address holes between them.

I wouldn't call it a big coincidence if the address of some
constant allocated 
in the constant data area had the same last 32 bits as
something from the 
heap, for example.

And 4Gb+ heaps are really nothing unheard of in more and
more workstation 
environments. I run an application which has about 2Gb of
heap allocated at 
any given time. On larger problem sets I envision it will
easily have triple 
that amount. If this application code, which is really a
library in a small 
executable wrapper, was linked into say a KDE application
which used the code 
in question, it'd break.

Cheers, Kuba

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Thursday February 14 2008 14:30:07 Kuba Ober wrote:

> I don't know how the memory is organized on 64 bit
machines, but presumably
> they have virtual memory too, and one then presumes
that say stack, heap
> and dynamic libraries can be possibly spread all over
the petabytes. Just
> like on some 32 bit platforms - heap, stack and library
code are nowhere
> near one another, there are huge address holes between
them.

Sure, it is possible, for the case where someone stores
pointers to objects on 
the stack in a hash. But it doesn't really change much.

>
> I wouldn't call it a big coincidence if the address of
some constant
> allocated in the constant data area had the same last
32 bits as something
> from the heap, for example.

It could happen, but it is just a hash collision. Which
means, it is a 
performance penalty *only*, and on average it should be much
smaller than 
doing bit shifting on every single hash lookup.

>
> And 4Gb+ heaps are really nothing unheard of in more
and more workstation
> environments. I run an application which has about 2Gb
of heap allocated at
> any given time. On larger problem sets I envision it
will easily have
> triple that amount. If this application code, which is
really a library in
> a small executable wrapper, was linked into say a KDE
application which
> used the code in question, it'd break.

It wouldn't break. It's a hash function, it's going to get
moduloed with some 
smallish number anyway. The hash function just need a
reasonable chance to 
get different results for different pointers, fast. The
latter is the reason 
why I wouldn't bitshift it with size_t, even though those
bits would likely 
nearly always be zero.

(And now I promise to shut up. I just couldn't let the
"it'd break" pass  )

-- 
regards, Esben

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel