 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / January 2008mySqlBytes.buffer is getting converted to BigEndian even though both SQL server 2005 and the CLR function are on the same machine which shows BitConverter.IsLittleEndian == true
mySqlBytes.buffer is getting converted to BigEndian even though both SQL server 2005 and the CLR function are on the same machine which shows BitConverter.IsLittleEndian == true in tsql: select * from dbo.MY_CLR_FUNCTION(cast(1024 as binary(4))) public static int MY_CLR_FUNCTION(SqlBytes mySqlBytes) in debugger binaryData.buffer now shows bigendian!! [0] 0 byte [1] 0 byte [2] 4 byte [3] 0 byte the data stays littleendian if the integer is hard coded in C#: int myint; myint = 1024; byte[] b = new byte[4]; b = BitConverter.GetBytes(myint); in debugger binaryData.buffer shows littleendian [0] 0 byte [1] 4 byte [2] 0 byte [3] 0 byte in all cases BitConverter.IsLittleEndian shows true, so why is the integer hard coded in tsql getting converted to big endian when it arrives in a clr function? > in debugger binaryData.buffer now shows bigendian!! > [0] 0 byte > [1] 0 byte > [2] 4 byte > [3] 0 byte That is little-endian, as the most significant byte is last. This is typical of x86 processors, and is used by Windows for storage. > in debugger binaryData.buffer shows littleendian > [0] 0 byte > [1] 4 byte > [2] 0 byte > [3] 0 byte This is big-endian, as the most significant byte is the first. The BitConverter's IsLittleEndian property indicates the endianness of the computer architecture. So, it will not change, except on a different computer.  SignatureHTH, Kevin Spencer Chicken Salad Surgeon Microsoft MVP > mySqlBytes.buffer is getting converted to BigEndian even though both SQL > server 2005 and the CLR function are on the same machine which shows [quoted text clipped - 25 lines] > hard coded in tsql getting converted to big endian when it arrives in a > clr function? > > in debugger binaryData.buffer now shows bigendian!! > > [0] 0 byte [quoted text clipped - 4 lines] > That is little-endian, as the most significant byte is last. This is typical > of x86 processors, and is used by Windows for storage. No, the most significant byte is first: 1024=0*2^24 + 0*2^16 + 4*2^8 + 0*2^0 Hence it's big-endian. Short test app for BitConverter to demonstrate: using System; using System.Collections.Generic; class Program { static void Main(string[] args) { byte[] bytes = BitConverter.GetBytes(1024); for (int i=0; i < bytes.Length; i++) { Console.WriteLine ("bytes[{0}]={1}", i, bytes[i]); } Console.WriteLine ("LittleEndian? {0}", BitConverter.IsLittleEndian); } } On my box that shows: bytes[0]=0 bytes[1]=4 bytes[2]=0 bytes[3]=0 LittleEndian? True So the pattern quoted at the top of this post (where [1]=0, [2]=4) is big endian. Jon Sorry, Jon. I used a calculator to check my figures, and I misread the results. I do a lot of work with files that may be big- or little-endian, and wrote the routines to read them correctly, but that was some time ago. Put it down to early morning syndrome. My math skills improve as the day wears on! SignatureKevin Spencer Chicken Salad Surgeon Microsoft MVP 4*2^8 = >> > in debugger binaryData.buffer now shows bigendian!! >> > [0] 0 byte [quoted text clipped - 41 lines] > > Jon jon is right, it the original post is correct on endianness. but the question still stands, why does every windows product use little endian accept sql server's convert to varbinary use big endian? >> in debugger binaryData.buffer now shows bigendian!! >> [0] 0 byte [quoted text clipped - 46 lines] >> integer hard coded in tsql getting converted to big endian when it >> arrives in a clr function? I'm thinking this is a bug in sql server to use big endian. Hopefully future versions of sql server will consistantly use little endian per the Microsoft standard. > jon is right, it the original post is correct on endianness. but the > question still stands, why does every windows product use little endian [quoted text clipped - 50 lines] >>> integer hard coded in tsql getting converted to big endian when it >>> arrives in a clr function? > I'm thinking this is a bug in sql server to use big endian. Hopefully future > versions of sql server will consistantly use little endian per the Microsoft > standard. While it's certainly slightly odd that it uses big endian (without specifically documenting it) I certainly hope MS has more concern for backward compatibility than to change the conversion at this stage. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.