Solved

reading unsigned bytes from a file

Posted on 1997-05-12
2
369 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

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
network + 7 80
Java / Linux and Regular Expressions 11 71
GUI builder for Eclipse? 8 27
Groovy problem when using SOAPUI : DispatchException occurred 7 27
For customizing the look of your lightweight component and making it look opaque like it was made of plastic.  This tip assumes your component to be of rectangular shape and completely opaque.   (CODE)
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…
This tutorial covers a practical example of lazy loading technique and early loading technique in a Singleton Design Pattern.
This theoretical tutorial explains exceptions, reasons for exceptions, different categories of exception and exception hierarchy.

895 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

12 Experts available now in Live!

Get 1:1 Help Now