?
Solved

reading unsigned bytes from a file

Posted on 1997-05-12
2
Medium Priority
?
382 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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 200 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

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This was posted to the Netbeans forum a Feb, 2010 and I also sent it to Verisign. Who didn't help much in my struggles to get my application signed. ------------------------- Start The idea here is to target your cell phones with the correct…
Java functions are among the best things for programmers to work with as Java sites can be very easy to read and prepare. Java especially simplifies many processes in the coding industry as it helps integrate many forms of technology and different d…
Viewers will learn about the different types of variables in Java and how to declare them. Decide the type of variable desired: Put the keyword corresponding to the type of variable in front of the variable name: Use the equal sign to assign a v…
Viewers will learn about arithmetic and Boolean expressions in Java and the logical operators used to create Boolean expressions. We will cover the symbols used for arithmetic expressions and define each logical operator and how to use them in Boole…
Suggested Courses
Course of the Month9 days, 22 hours left to enroll

762 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