471,339 Members | 1,242 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,339 software developers and data experts.

Is Convert.ToSByte buggy or am I buggy?

Using v1.1. of the framework:

I was writing a wrapper around the java.util.zip.ZipOutputStream 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(false)]
public static sbyte ToSByte(byte value)
{
if (value > 0x7f)
{
throw new
OverflowException(Environment.GetResourceString("O verflow_SByte"));
}
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;

Jul 21 '05 #1
4 2496
>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.BlockCopy 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.
Jul 21 '05 #2
> 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.
Jul 21 '05 #3

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:ui**************@TK2MSFTNGP14.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.BlockCopy 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.
Jul 21 '05 #4

"Bruno Jouhier [MVP]" <bj******@club-internet.fr> wrote in message
news:Og**************@TK2MSFTNGP15.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
Jul 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Ray Ackley | last post: by
4 posts views Thread by David Levine | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.