silly unsigned/signed byte conversion question

[aspa]

after having worked too long with weakly typed programming languages
it was only recently when i came to realize that the byte stream io
and some other methods using a buffer array for storing data
(InputStream.read(byte[]) et al.) don't really automatically work with
8-bit data because byte is a signed type in Java. so, after this
observation i'm curious: what is the best technique, performance and
otherwise, of converting between 8-bit unsigned and signed bytes in
Java?

best regards,

 

[Brad BARCLAY]

after having worked too long with weakly typed programming languages
it was only recently when i came to realize that the byte stream io
and some other methods using a buffer array for storing data
(InputStream.read(byte[]) et al.) don't really automatically work with
8-bit data because byte is a signed type in Java. so, after this
observation i'm curious: what is the best technique, performance and
otherwise, of converting between 8-bit unsigned and signed bytes in
Java?

Why even bother to convert? I typically leave them as-is. If I need
to do a conversion between the byte and it's unsigned value, I have an
"UnsignedByte" class that handles it (and a few other useful tasks --
see (long URL warning!!!):

http://cvs.sourceforge.net/viewcvs....gnedByte.java?content-type=text/plain&rev=3.0

Brad BARCLAY

 

[Harald Hein]

it was only recently when i came to realize that the byte stream
io and some other methods using a buffer array for storing data
(InputStream.read(byte[]) et al.) don't really automatically work
with 8-bit data because byte is a signed type in Java.

They work. You just have to be careful when you convert the byte to
some other type, like an int. You have to mask out the sign-extension.

so, after
this observation

Your observation is wrong.

i'm curious: what is the best technique,
performance and otherwise, of converting between 8-bit unsigned
and signed bytes in Java?

There are no unsigned bytes in Java. So where do you convert from?

 

[Steve Horsley]

after having worked too long with weakly typed programming languages
it was only recently when i came to realize that the byte stream io
and some other methods using a buffer array for storing data
(InputStream.read(byte[]) et al.) don't really automatically work with
8-bit data because byte is a signed type in Java. so, after this
observation i'm curious: what is the best technique, performance and
otherwise, of converting between 8-bit unsigned and signed bytes in
Java?

best regards,

Java has no such type as an unsigned byte. If you insist on regarding all
bytes as positive values (as my brain does) than you must convert to a
different type - short, int, long or (shudder) char. Beware of sign
extension as you convert - a byte containing 0xFF is value -1 which
when extended to an int becomes -1 (0xFFFFFFFF). To coerce it into the
range 0-255 you must remove the sign extension like this:
int x = myByte & 255;

<opinion>
Whoever decided that byte was signed was as mad as a bucket of frogs, but
the deed is done now, and people will shake their heads in wonder for ever
more.
</opinion>

For efficiency, I guess it is best to accept that bytes are signed, and
not try to convert to other types at all. If you are working with bytes,
then work with bytes. -128...+127. Live with it. What's the problem?
Instead of "if b > 127", use "if b < 0". It can be done.

Steve

 

[Roedy Green]

If you are working with bytes,
then work with bytes. -128...+127.

that does not work if you using bytes to do things like flip
endianness -- taking apart and reconstructing larger blocks.

I think Java the language could acquire a octet type (unsigned byte).
No new JVM instructions are needed. The compiler could just insert
AND 0xff all over the place. All you need is another type in the class
files for parameters etc.

 

[aspa]

Java has no such type as an unsigned byte.

you're right. i was misleadingly trying to refer to an octet value's
"unsigned" representation as short, int or long.

<opinion>
Whoever decided that byte was signed was as mad as a bucket of frogs, but
the deed is done now, and people will shake their heads in wonder for ever
more.

and some of us, in confusion too

</opinion>

For efficiency, I guess it is best to accept that bytes are signed, and
not try to convert to other types at all. If you are working with bytes,
then work with bytes. -128...+127. Live with it. What's the problem?
Instead of "if b > 127", use "if b < 0". It can be done.

my original problem was reading 8-bit data from a character stream and
then interpreting that data like in the following peace of code:

File file = new File("/foo/data.d");
int len = (int)file.length();
byte[] buffer = new byte[len];
FileInputStream fis = new FileInputStream(file);
int n = fis.read(buffer, 0, len);
fis.close();
for(int i=0; i<n; i++) {
int d = buffer & 0xff;
System.out.print(Integer.toHexString(d)+" ");
}
System.out.println();

this seems to work fine, now.

thanks for the help!

best regards,

 

[aspa]

There are no unsigned bytes in Java. So where do you convert from?

i meant to say "unsigned" representation of an octet.

it was the sign extension when converting from byte to int that was
confusing me. i was converting byte data to int and didn't know it.

best regards,

 

[Dale King]

that does not work if you using bytes to do things like flip
endianness -- taking apart and reconstructing larger blocks.

I think Java the language could acquire a octet type (unsigned byte).

And I think octet would be a good name for the type. But this of course
introduces another new keyword.

No new JVM instructions are needed. The compiler could just insert
AND 0xff all over the place. All you need is another type in the class
files for parameters etc.

But that unfortunately breaks backwards compatibility in the case that you
have some classes compiled with pre-octet compilers and some with octet
aware compilers.

I'm really beginning to think the time is ripe for making a jump in the JVM
to support all the things that are sort of hacked in like class constants,
generics, nested classes etc. And an unsigned byte type would be a good
addition as well.

 

[Steve Horsley]

Java has no such type as an unsigned byte.

you're right. i was misleadingly trying to refer to an octet value's
"unsigned" representation as short, int or long.

<opinion>
Whoever decided that byte was signed was as mad as a bucket of frogs, but
the deed is done now, and people will shake their heads in wonder for ever
more.

and some of us, in confusion too

</opinion>

For efficiency, I guess it is best to accept that bytes are signed, and
not try to convert to other types at all. If you are working with bytes,
then work with bytes. -128...+127. Live with it. What's the problem?
Instead of "if b > 127", use "if b < 0". It can be done.

my original problem was reading 8-bit data from a character stream and
then interpreting that data like in the following peace of code:

File file = new File("/foo/data.d");
int len = (int)file.length();
byte[] buffer = new byte[len];
FileInputStream fis = new FileInputStream(file);
int n = fis.read(buffer, 0, len);
fis.close();
for(int i=0; i<n; i++) {
int d = buffer & 0xff;
System.out.print(Integer.toHexString(d)+" ");
}
System.out.println();

this seems to work fine, now.

It's not reliable. You have a bug.
There is no guarantee that that single read will get all the bytes in the
file in one go. You _must_ check the return value and go back for more if
the read didn't get it all. AS it is now, your program may exhibit strange
"corruption", particularly using files on network shares.

Steve

 

[Roedy Green]

What's with these Marilyn Monroe "silly" questions?

Why are you all trying to pretend to be ditzy blondes?

Is the idea to appeal to male chivalry?

Is the idea to beat yourself publicly so Paul Lutus won't do it for
you?

Perhaps you mean "easy" question.

There is nothing silly at all about the questions labelled "silly".