Hello all. When building OCC6.1 on a amd x64 with platform sdk version 14.00.40310.41, i get a LOT of 64 bits portability warnings like this:
c:\CAS6.1.0\ros\inc\gp.hxx(98) : warning C4267: 'argument' : conversion from 'si
ze_t' to 'const Standard_Integer', possible loss of data
c:\CAS6.1.0\ros\inc\Handle_Standard_Transient.hxx(39) : warning C4312: 'type cas
t' : conversion from 'unsigned int' to 'Standard_Transient *' of greater size
which seems that could cause problems... There is also code that applies to the DEC Alpha (with the __ALPHA define) which could apply also for an AMD64 like in Handle_Standard_Transient.hxx line 18.
We also need to fix a cast error in Standard_Address::HashCode to compile correctly.
So for those who builded OCC on 64 bits platform did you correct the warnings (like replacing the definition of Standard_Integer with an _int64 instead of int) or just ignored them? Or maybe i'm not using the correct download (i used OpenCASCADE_win32.exe version 6.1).
As for myself i ignored the warnings and some of our applications returns weird results but i need to debug them fully to confirm the cause.
Windows 64bit uses LLP64. http://en.wikipedia.org/wiki/ILP64#64-bit_data_models
This means, that integer and long are 32bit, but pointer are 64bit. So casting a pointer to long or int will loose information. If a adress larger than the maximal value of int/long is used and you cast it to int/long and back, strange thins will happen. If you have luck, it is directly a segmentation fault.
So this means that right out of the box OCC 6.1 doesn't support correctly win64 since i have a multitude of portability warnings trying to build it. What do you think?
Thanks for your help,
Yes, I think there are bugs, caused by incorrect use of types.
I think, all shoud work fine, if you don't have more memory than a integer can adress. But beyond that...
On Linux or Solaris 64bit should be similar problems, since int is there 32bit to.