Solved

reading unsigned bytes from a file

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

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

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

Suggested Solutions

An old method to applying the Singleton pattern in your Java code is to check if a static instance, defined in the same class that needs to be instantiated once and only once, is null and then create a new instance; otherwise, the pre-existing insta…
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 learn about the “for” loop and how it works in Java. By comparing it to the while loop learned before, viewers can make the transition easily. You will learn about the formatting of the for loop as we write a program that prints even numbers…
Viewers will learn about basic arrays, how to declare them, and how to use them. Introduction and definition: Declare an array and cover the syntax of declaring them: Initialize every index in the created array: Example/Features of a basic arr…

821 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