Is Convert.ToSByte buggy or am I buggy?

[David Levine]

Using v1.1. of the framework:

I was writing a wrapper around the java.util.zip.Z ipOutputStream class so
that my app could access it using standard FileStream semantics and I ran
into a conversion problem. The signature for the write method is void
ZipOutputStream .Write(sbyte[] array,int off,int len) so I figured a simple
conversion from byte[] to sbyte[] would do the trick.

Now, my understanding of an sbyte is that it is a signed byte that can hold
values from -128 to 127. In hex 0x00 through 0x7f are positive values and
0x80 through 0xff are negative values.

When I wrote some test data the routine Convert.ToSbyte (byte) would throw an
overflow exception; this occurred for any value in the range of 0x80 - 0xff.
I then used Reflector to look at the BCL for Convert.ToSByte and the code
is...

[CLSCompliant(fa lse)]
public static sbyte ToSByte(byte value)
{
if (value > 0x7f)
{
throw new
OverflowExcepti on(Environment. GetResourceStri ng("Overflow_SB yte"));
}
return (sbyte) value;
}

This surprised me - it specifically disallows all values that would result
in a negative value for the sbyte. So, is the BCL correct or should it
convert it to a negative value?

BTW: I wrote my own conversion method, tested it, and it all seems to work
correctly for all possible values of a byte.
if ( b > 0x7f )
sb = (sbyte)(0 - (0xff - b))
else
sb = (sbyte)b;

[Mattias Sjögren]

>so I figured a simple

conversion from byte[] to sbyte[] would do the trick.

If that's what you want to do, I think calling Buffer.BlockCop y is the
easiest way to go. Then you don't have to worry about overflows.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Bruno Jouhier [MVP]]

> BTW: I wrote my own conversion method, tested it, and it all seems to work

correctly for all possible values of a byte.
if ( b > 0x7f )
sb = (sbyte)(0 - (0xff - b))
else
sb = (sbyte)b;

sb = (sbyte)b (without any test) will work as well, and will be faster!

Bruno.

[David Levine]

"Mattias Sjögren" <ma************ ********@mvps.o rg> wrote in message
news:ui******** ******@TK2MSFTN GP14.phx.gbl...

so I figured a simple
conversion from byte[] to sbyte[] would do the trick.

If that's what you want to do, I think calling Buffer.BlockCop y is the
easiest way to go. Then you don't have to worry about overflows.

Thanks, I never even knew that class existed. It did the trick.

[David Levine]

"Bruno Jouhier [MVP]" <bj******@clu b-internet.fr> wrote in message
news:Og******** ******@TK2MSFTN GP15.phx.gbl...

BTW: I wrote my own conversion method, tested it, and it all seems to
work correctly for all possible values of a byte.
if ( b > 0x7f )
sb = (sbyte)(0 - (0xff - b))
else
sb = (sbyte)b;

sb = (sbyte)b (without any test) will work as well, and will be faster!

Yah, that occurred to me after I sent out the msg. I originally wrote it
because I figured if it was easy as doing a direct cast then Convert would
have used it without checking for the overflow. I still haven't figured out
why they think it's an overflow and why they would disallow those values.
Thanks