On August 11th in the newsgroup sybase.public.ase.general, Tartampion raised the issue that ASE’s bitwise operations were not platform independent.
When we run the statement "select 0 | 0x00000020" on 2 of our servers, we obtain different results 1: sun Solaris Sybase version: Adaptive Server Enterprise/12.5.3/EBF 13398 ESD#6 ONE-OFF/P/Sun_svr4/OS 5.8/ase1253/1947/32-bit/FBO/Tue Mar 7 04:50:16 2006 select 0 | 0x00000020 --- 32 2: Linux: Sybase version:Adaptive Server Enterprise/12.5.3/EBF 13400 ESD#6 ONE-OFF/P/Linux Intel/Enterprise Linux/ase1253/1947/32-bit/OPT/Mon Mar 6 20:22:17 2006 select 0 | 0x00000020 ------------- 536870912 This causes pb in our application behavior. I am writing to see if this is a normal behavior or we need to change configurations to obtain similar results. All help is well appreciated. Tartampion.
Sybase’s answer up to now has been that this is expected behavior and the following method should be used instead:
For safe conversions between hexadecimal and decimal use the platform independent inttohex() and hextoint():
select @@version select 0 | 0x00000020, 0 | convert( int, 0x00000020 ), 0 | hextoint('0x00000020' )
The problem with Sybase’s response is that it is inconsistant with how Sybase pushes ASE as being the same running on any supported platform from the client application.
There is quite a bit of os/hardware specific code within ASE. This just happens to be one such legacy chunk of code where the bitwise operation is performed in a os specific manner rather than an independent manner. Anthony Mandic, myself and others are pushing for Sybase to correct this legacy operation to be platform independent. No bug # (cr#) exists at this time but we should be receiving one within a few days.