Strange results in bitwise operations

[Fabrício de Novaes Kucinskis]

Hi all,
I'm doing some bitwise operations in VB.NET, and I got some strange results.
If an Int16 (Short) variable has the value &HAA (8 bits) and I do a 4-bit
shift:

var16 = var16 << 4

I got, correctly, the value &HAA0. But, if I try to do a 8-bit shift, I got
&HFFFFAA00 !!!!
I did many tests and it appears that I need a 32-bit variable to do
operations that normally - in other platforms - I can do in 16-bit
variables!
Does someone knows why? I've lost some hours of my life to outline - but not
solve - this, and I'd like to know, at least, why.

Thanks in advance,
Fabrício de Novaes Kucinskis.

[Carl Daniel [VC++ MVP]]

Fabrício de Novaes Kucinskis wrote:

Hi all,
I'm doing some bitwise operations in VB.NET,
Odd that you posted to a C# group, a C++ group, but no VB.NET group...
and I got some strange
results. If an Int16 (Short) variable has the value &HAA (8 bits) and
I do a 4-bit shift:

var16 = var16 << 4

I got, correctly, the value &HAA0. But, if I try to do a 8-bit shift,
I got &HFFFFAA00 !!!!
This is because Int16 is a signed type, so .NET sign-extends that value when
it's converted to 32-bits. Note that an Int16 can't hold 0xFFFFAA00 - the
sign-extension is being done when the value is converted to an Int32, most
likely on the way to being converted to a string (I assume you're displaying
it in a window, or converting it to a string, etc).
I did many tests and it appears that I need a 32-bit variable to do
operations that normally - in other platforms - I can do in 16-bit
variables!
Does someone knows why? I've lost some hours of my life to outline -
but not solve - this, and I'd like to know, at least, why.

The bits behave the same way they always have - you're just not accounting
for sign-extensions when converting to a 32-bit type.

-cd

[Fabrício de Novaes Kucinskis]

Hi, Carl. I'm sorry for the group's mistake.

I'm not converting my values to 32-bit, neither showing or converting then
to strings.
I'm working directly with the numeric vars, and I got the values in the
watch window.

A simple example of what is happening here:

dim var16 as Int16 '(or short)
var16 = &HAA
var16 = CType(var16 << 4, Int16) 'result expected: &HAA0 - ok!
var16 = &HAA
var16 = CType(var16 << 8, Int16) 'result expected: &HAA00; result:
&HFFFFAA00

I'm not sure, but I think there's no 32-bit convertion here. Or there is?
Thanks for the help.

Best regards,
Fabrício.

and I got some strange
results. If an Int16 (Short) variable has the value &HAA (8 bits) and
I do a 4-bit shift:

var16 = var16 << 4

I got, correctly, the value &HAA0. But, if I try to do a 8-bit shift,
I got &HFFFFAA00 !!!!
This is because Int16 is a signed type, so .NET sign-extends that value

when it's converted to 32-bits. Note that an Int16 can't hold 0xFFFFAA00 - the
sign-extension is being done when the value is converted to an Int32, most
likely on the way to being converted to a string (I assume you're displaying it in a window, or converting it to a string, etc).

I did many tests and it appears that I need a 32-bit variable to do
operations that normally - in other platforms - I can do in 16-bit
variables!
Does someone knows why? I've lost some hours of my life to outline -
but not solve - this, and I'd like to know, at least, why.

The bits behave the same way they always have - you're just not accounting
for sign-extensions when converting to a 32-bit type.

[Carl Daniel [VC++ MVP]]

Fabrício de Novaes Kucinskis wrote:

Hi, Carl. I'm sorry for the group's mistake.

I'm not converting my values to 32-bit, neither showing or converting
then to strings.
I'm working directly with the numeric vars, and I got the values in
the watch window.

A simple example of what is happening here:

dim var16 as Int16 '(or short)
var16 = &HAA
var16 = CType(var16 << 4, Int16) 'result expected: &HAA0 - ok!
var16 = &HAA
var16 = CType(var16 << 8, Int16) 'result expected: &HAA00; result:
&HFFFFAA00

I'm not sure, but I think there's no 32-bit convertion here. Or there
is? Thanks for the help.

The debugger (or the .NET runtime) is widening it to 32 bits during the
conversion to string for display in the watch window. Nothing to be alarmed
about.

-cd

[Fabrício de Novaes Kucinskis]

Ok, so there is a string convertion! Thanks a lot!

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:eh**************@tk2msftngp13.phx.gbl...

Fabrício de Novaes Kucinskis wrote:

Hi, Carl. I'm sorry for the group's mistake.

I'm not converting my values to 32-bit, neither showing or converting
then to strings.
I'm working directly with the numeric vars, and I got the values in
the watch window.

A simple example of what is happening here:

dim var16 as Int16 '(or short)
var16 = &HAA
var16 = CType(var16 << 4, Int16) 'result expected: &HAA0 - ok!
var16 = &HAA
var16 = CType(var16 << 8, Int16) 'result expected: &HAA00; result:
&HFFFFAA00

I'm not sure, but I think there's no 32-bit convertion here. Or there
is? Thanks for the help.
The debugger (or the .NET runtime) is widening it to 32 bits during the
conversion to string for display in the watch window. Nothing to be

alarmed about.

-cd