BitConverter.To Int16() Trying to understand "behind the scenes"

[Lenn]

This probably something stupid, or I am missing some fundemantal concept, but
I can't figure this one out.

Consider the following code:

byte[] bd = new byte[2];
bd[0] = 0x00;
bd[1] = 0x01;

System.Int16 a;
a = System.BitConve rter.ToInt16(bd , 0);
MessageBox.Show (a.ToString());

BitConverter.To Int16 returns 16 bit signed integer at specified position in
a byte array.
So, one would think hex value 0x0001 is 1 in decimal, no the following code
produces 256 which is 0x0010. Now switch around values in byte array:

byte[] bd = new byte[2];
bd[0] = 0x01;
bd[1] = 0x00;

System.Int16 a;
a = System.BitConve rter.ToInt16(bd , 0);
MessageBox.Show (a.ToString());

The code above does produce 1. But hex 0x0100 is 256.

Can someone explain this?

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

It called little endian, a byte ( 16 bits ) are stored reversed, it's been
a architecture of Intel processors since the beginning, I don;t remember
right now the reasons though.

a search for little endian got me this link in google:
http://www.cs.umass.edu/~verts/cs32/endian.html
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Lenn" <Le**@discussio ns.microsoft.co m> wrote in message
news:61******** *************** ***********@mic rosoft.com...

This probably something stupid, or I am missing some fundemantal concept,
but
I can't figure this one out.

Consider the following code:

byte[] bd = new byte[2];
bd[0] = 0x00;
bd[1] = 0x01;

System.Int16 a;
a = System.BitConve rter.ToInt16(bd , 0);
MessageBox.Show (a.ToString());

BitConverter.To Int16 returns 16 bit signed integer at specified position
in
a byte array.
So, one would think hex value 0x0001 is 1 in decimal, no the following
code
produces 256 which is 0x0010. Now switch around values in byte array:

byte[] bd = new byte[2];
bd[0] = 0x01;
bd[1] = 0x00;

System.Int16 a;
a = System.BitConve rter.ToInt16(bd , 0);
MessageBox.Show (a.ToString());

The code above does produce 1. But hex 0x0100 is 256.

Can someone explain this?

[Sergei]

"Lenn" <Le**@discussio ns.microsoft.co m> wrote:

This probably something stupid, or I am missing some fundemantal concept, but
I can't figure this one out.

Consider the following code:

byte[] bd = new byte[2];
bd[0] = 0x00;
bd[1] = 0x01;

System.Int16 a;
a = System.BitConve rter.ToInt16(bd , 0);
MessageBox.Show (a.ToString());

BitConverter.To Int16 returns 16 bit signed integer at specified position in
a byte array.
So, one would think hex value 0x0001 is 1 in decimal, no the following code
produces 256 which is 0x0010. Now switch around values in byte array:

byte[] bd = new byte[2];
bd[0] = 0x01;
bd[1] = 0x00;

System.Int16 a;
a = System.BitConve rter.ToInt16(bd , 0);
MessageBox.Show (a.ToString());

The code above does produce 1. But hex 0x0100 is 256.

Can someone explain this?

The program runs on a little endian machine.
See static function BitConverter.Is LittleEndian

Sergei

[Bill Butler]

"Lenn" <Le**@discussio ns.microsoft.co m> wrote in message
news:61******** *************** ***********@mic rosoft.com...

This probably something stupid, or I am missing some fundemantal concept,
but
I can't figure this one out. <snip> byte[] bd = new byte[2];
bd[0] = 0x01;
bd[1] = 0x00;

System.Int16 a;
a = System.BitConve rter.ToInt16(bd , 0);
MessageBox.Show (a.ToString());

The code above does produce 1. But hex 0x0100 is 256.

Can someone explain this?

Yes.

the data is stored in little-endian order //low order bytes before high
order bytes
This is the Norm for Windows based systems.

Other Some operating systems use Big-endian ordering.
I think Linux varies by the machine it runs on. (Not sure on this)

This is one of the reasons that it is difficult to transfer binary data
between different systems.
You need to agree which endianness is the "Correct" one.

Hope this helps
Bill

[Helge Jensen]

Lenn wrote:

This probably something stupid, or I am missing some fundemantal concept, but
I can't figure this one out.

There are two (actually more, but common anyway :) ways to write
composed numbers: Most or Least Significant Byte first (MSB/LSB,
Big/Little-endian respectively). MSB is the usual notation used by
humans. LSB is used by many CPU's, including x86 variants.

(int)0x01020304

in MSB:

[0x01,0x02,0x03, 0x04]

in LSB:

[0x04,0x03,0x02, 0x01]

You can check in BitConverter.Is LittleEndian what endianness
BitConverter will use.

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Lenn]

Thank you all.

I had no knoweledge about Little endian.
They probably had good reasons to do that. I wonder what they are. I hope it
wasn't to confuse me :)

That brings another question. What are the specific cases when I need to
worry about it.
For example this code:

int x = 0;
x = 0x0001;
MessageBox.Show (x.ToString());

works as expected, so my hex 0x0001 represntation of 1 internally is really
stored as 0100. But if I wanted to create a byte array with 2 elements
representing 16-bit integer I would put 0x01 before 0x00, right? Can you tell
me any other gotchas?

"Helge Jensen" wrote:

Lenn wrote:

This probably something stupid, or I am missing some fundemantal concept, but
I can't figure this one out.

There are two (actually more, but common anyway :) ways to write
composed numbers: Most or Least Significant Byte first (MSB/LSB,
Big/Little-endian respectively). MSB is the usual notation used by
humans. LSB is used by many CPU's, including x86 variants.

(int)0x01020304

in MSB:

[0x01,0x02,0x03, 0x04]

in LSB:

[0x04,0x03,0x02, 0x01]

You can check in BitConverter.Is LittleEndian what endianness
BitConverter will use.

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Jon Skeet [C# MVP]]

Lenn <Le**@discussio ns.microsoft.co m> wrote:

I had no knoweledge about Little endian.
They probably had good reasons to do that. I wonder what they are. I hope it
wasn't to confuse me :)

That brings another question. What are the specific cases when I need to
worry about it.
For example this code:

int x = 0;
x = 0x0001;
MessageBox.Show (x.ToString());

works as expected, so my hex 0x0001 represntation of 1 internally is really
stored as 0100. But if I wanted to create a byte array with 2 elements
representing 16-bit integer I would put 0x01 before 0x00, right? Can you tell
me any other gotchas?

It's really only when you want to convert to or from a byte array - a
bit like converting characters using a specific encoding.

While you're within the confines of actual numbers, the endianness
doesn't matter at all, as you've seen - 0x0001 is 1 whatever the
endianness is.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[James Curran]

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.mach in AT dot.state.fl.us > wrote
in message news:Or******** ******@tk2msftn gp13.phx.gbl...

It called little endian, a byte ( 16 bits ) are stored reversed, it's been a architecture of Intel processors since the beginning, I don;t remember
right now the reasons though.

They aren't "reversed". And Intel's reason for doing it this way is
because it's the most natural & correct way of doing it. Little Endian
order puts the lowest order byte at the lowest order address. It merely
appears "reversed" due to the way English-speaking humans read hardcopy
print-out of hex dumps.

--
--
Truth,
James Curran
[erstwhile VC++ MVP]

Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com