Solved

reading unsigned bytes from a file

Posted on 1997-05-12
2
364 Views
Last Modified: 2008-03-06
I am using readUnsignedByte() to get unsigned byte values
from a file. The problem is, its to slow. I need something
like readFully(unsigned byte[], ... ). I am reading large
files and I need to read them fast. I have tried the
read(byte[], ... ) and casting the result but the problem
with this is that (byte)255 = 0. Does anyone know the solution to this problem?
0
Comment
Question by:javap
  • 2
2 Comments
 
LVL 6

Expert Comment

by:jpk041897
ID: 1220371
Following is a mailing list posting that you might find relevant:

> From: Chuck McManis <cmcmanis@netcom.com>
> To: Tim Wolters <twolters@requisite.com>
> Cc: 'Advanced Java List' <advanced-java@xcf.berkeley.edu>
> Subject: Re: Long.parseLong works differently in 1.1
> Date: Monday, April 14, 1997 12:07 PM
>
> Tim Wolters wrote:
> > With the 1.1 JVM I get a NumberFormatException for hex values that
> > are > Long.MAX, but still valid 64 bit values.
>
> > The 1.0.2 JVM processes these fine.
>
> Well I don't know if its relevant or not, but I had a long running
> 'discussion' with Bill Joy about this when the language spec was
> undergoing review. The issue I had was as follows:
>       byte b = 255;      
> is clearly wrong since '255' won't fit into a byte but '-1' will.
> The compiler would complain and ask for a cast.
>       byte b = 0xff;
> is also clearly wrong (in my opinion) since you've expressed the
> bit pattern as a positive number.
>
> Now my issue arose when I was designing the large integer package
> and needed to deal with how one dealt with numbers expressed in hex.
> In particular, if your integers have no fixed size, then you can
> always add more bits of precision so that any hex number you give
> it is represented as a postive number, so 0xfffffffffffffffffffffffff
> is never -1. However, you then could _not_ specify a number in hex
> that you wanted to be negative easily (how many bits would you give
> to -1 ? )[ed. answer=2]
>
> My argument was that as Java wasn't C, we should "do the correct
> and consistent" thing and make hex constants that were larger than
> the native size of the container an error, and when you cast a
> representation of a positive constant into a data type of less
> precision you always got a positive constant, so casting  0xff
> to a byte you got 0x7F not -1. (similarly casting 255 to a byte
> would give you 127). I believe the response was "That's stupid,
> it would just piss off all the C programmers." :-) [Which is true
> of course, it would]. Needless to say I lost the arguement well
> before 1.0beta shipped and the rest is history.
>
> It sounds a bit like someone revisited the issue and changed their
> mind. Perhaps the source code has a comment in it to explain why it
> was changed.
>
> --Chuck



As you can see, signed unsigned transfer is an undefined bloody mess.

My sugestion to you would be to open a URL and assign it to a BufferedInputStream. This will allow you to read in the char file using buffers, which would allow for much faster input. Then you could cast the contents, first to int and then to unsighned byte in memory. This would avoid the (byte(255) = 0 problem.
0
 
LVL 6

Accepted Solution

by:
jpk041897 earned 100 total points
ID: 1220372
As per your request, I am posting the comment as an answer. (Thanks)


Following is a mailing list posting that you might find relevant:

> From: Chuck McManis <cmcmanis@netcom.com>
> To: Tim Wolters <twolters@requisite.com>
> Cc: 'Advanced Java List' <advanced-java@xcf.berkeley.edu>
> Subject: Re: Long.parseLong works differently in 1.1
> Date: Monday, April 14, 1997 12:07 PM
>
> Tim Wolters wrote:
> > With the 1.1 JVM I get a NumberFormatException for hex values that
> > are > Long.MAX, but still valid 64 bit values.
>
> > The 1.0.2 JVM processes these fine.
>
> Well I don't know if its relevant or not, but I had a long running
> 'discussion' with Bill Joy about this when the language spec was
> undergoing review. The issue I had was as follows:
> byte b = 255;
> is clearly wrong since '255' won't fit into a byte but '-1' will.
> The compiler would complain and ask for a cast.
> byte b = 0xff;
> is also clearly wrong (in my opinion) since you've expressed the
> bit pattern as a positive number.
>
> Now my issue arose when I was designing the large integer package
> and needed to deal with how one dealt with numbers expressed in hex.
> In particular, if your integers have no fixed size, then you can
> always add more bits of precision so that any hex number you give
> it is represented as a postive number, so 0xfffffffffffffffffffffffff
> is never -1. However, you then could _not_ specify a number in hex
> that you wanted to be negative easily (how many bits would you give
> to -1 ? )[ed. answer=2]
>
> My argument was that as Java wasn't C, we should "do the correct
> and consistent" thing and make hex constants that were larger than
> the native size of the container an error, and when you cast a
> representation of a positive constant into a data type of less
> precision you always got a positive constant, so casting 0xff
> to a byte you got 0x7F not -1. (similarly casting 255 to a byte
> would give you 127). I believe the response was "That's stupid,
> it would just piss off all the C programmers." :-) [Which is true
> of course, it would]. Needless to say I lost the arguement well
> before 1.0beta shipped and the rest is history.
>
> It sounds a bit like someone revisited the issue and changed their
> mind. Perhaps the source code has a comment in it to explain why it
> was changed.
>
> --Chuck



As you can see, signed unsigned transfer is an undefined bloody mess.

My sugestion to you would be to open a URL and assign it to a BufferedInputStream. This will allow you to read in the char file using buffers, which would allow for much faster input. Then you could cast the contents, first to int and then to unsighned byte in memory. This would avoid the (byte(255) = 0 problem.
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Java contains several comparison operators (e.g., <, <=, >, >=, ==, !=) that allow you to compare primitive values. However, these operators cannot be used to compare the contents of objects. Interface Comparable is used to allow objects of a cl…
In this post we will learn how to connect and configure Android Device (Smartphone etc.) with Android Studio. After that we will run a simple Hello World Program.
Viewers learn how to read error messages and identify possible mistakes that could cause hours of frustration. Coding is as much about debugging your code as it is about writing it. Define Error Message: Line Numbers: Type of Error: Break Down…
Viewers will learn how to properly install Eclipse with the necessary JDK, and will take a look at an introductory Java program. Download Eclipse installation zip file: Extract files from zip file: Download and install JDK 8: Open Eclipse and …

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now