Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

reading unsigned bytes from a file

Posted on 1997-05-12
2
Medium Priority
?
386 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

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

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…
Introduction This article is the second of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article covers the basic installation and configuration of the test automation tools used by…
Viewers learn about the third conditional statement “else if” and use it in an example program. Then additional information about conditional statements is provided, covering the topic thoroughly. Viewers learn about the third conditional statement …
This theoretical tutorial explains exceptions, reasons for exceptions, different categories of exception and exception hierarchy.

604 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