Re: 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

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance




"Stephany Young" <noone@localhost> wrote in message
news:OAE6o52TIHA.4880@xxxxxxxxxxxxxxxxxxxxxxx
I'll try and put it another way. It is NOT big-endian! It is no-endian!

The cast makes no assumption about the source data and 'gives' you the
bytes
from left to right without otherwise massaging them in any way.

The behavior the OP claims to observe is that the cast, not BitConverter, is
reversing the bytes.


You do not need documentation to support this. This is what you are
observing.

Here's what the documentation
http://msdn2.microsoft.com/en-us/library/ms187928.aspx says:

SQL Server guarantees that only roundtrip conversions, conversions that
convert a data type from its original data type and back again, will yield
the same values from version to version.
Note:
Do not try to construct binary values and then convert them to a data
type of the numeric data type category. SQL Server does not guarantee that
the result of a decimal or numeric data type conversion to binary will be
the same between versions of SQL Server.



It is the BitConverter class that 'knows' to return the bytes for an int
reversed (big-endian).


"DR" <softwareengineer98037@xxxxxxxxx> wrote in message
news:%23o2Qrr0TIHA.1164@xxxxxxxxxxxxxxxxxxxxxxx
do you have some documentation to back this up? so far all i can do is
test this to verify that tsql's cast is giving me data that comes into
clr
as big endian. any documentation on this behavior in msdn?

"Stephany Young" <noone@localhost> wrote in message
news:OBqN5O0TIHA.4752@xxxxxxxxxxxxxxxxxxxxxxx
The point is that it is not being converted to any-endian.

binary(4) is nothing more that a buffer of bytes and cast(... as
binary(4)) is certainly NOT analogous to BitConverter.GetBytes(int).

If you want it correctly then pass the int (intact) to the function and
use BitConverter inside the function.


"DR" <softwareengineer98037@xxxxxxxxx> wrote in message
news:%23xjDDkyTIHA.5980@xxxxxxxxxxxxxxxxxxxxxxx
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?







begin 666 ms187928.note(en-US,SQL.90).gif
M1TE&.#EA"@`*`+,)`/\$`/]=6L;#QM;3UO_/`(2&A(R.C ```/__SO___P``
M`````````````````````"'Y! $```D`+ `````*``H```0HT,@Y1 `&Z7T(
AWEIW)!E'C.16G$.2(L-1((5;%D-H@_H+HH>@,.B*```[
`
end

.



Relevant Pages

  • Re: mySqlBytes.buffer is getting converted to BigEndian even though both SQL server 2005 and the CLR
    ... The cast makes no assumption about the source data and 'gives' you the bytes from left to right without otherwise massaging them in any way. ... If you want it correctly then pass the int to the function and use BitConverter inside the function. ... 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? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: replicate?
    ... use the cast or convert function to change the data type to int. ... it will automatically drop the leading zeroes. ...
    (microsoft.public.sqlserver.programming)
  • Re: Newbie question about malloc
    ... "Implicit int" no longer exists in C. ... It's generally recommended to NOT cast the return from malloc. ... %d can never be the correct format specifier for a size_t. ... C99 introduced %zu for this purpose, ...
    (comp.lang.c)
  • Re: Freeing Algorithms
    ... On the other hand, int is simple, efficient, and handles very ... The data type int falls somewhere before the requirement of the user. ... To paraphrase the requirement (since requirements cannot be accurately expressed in English (or a programming language for the Mr. TDD!)), a data type that extended between negative and positive infinity is required to express the arrow of time. ... Assuming Java provided a data type that permitted an extension to infinity, then it would certainly make int look like hitherto "overkill". ...
    (comp.lang.java.programmer)
  • Re: what will happen after i use free()???
    ... Inserting a cast before malloc is not needed, ... 56 bits while int is only 48 bits. ... So casting that value requires some ... Use cast only if you are absolutely sure that yor really needs the ...
    (comp.lang.c)