Unsigned type

I try to explain my problem:
I capture, with of the get, the data from a structure MIB in which they
they are stored.
The method that I use, gives back a Object to me.
I must packet this values in a message with a structure the whose
fields have different types (unsigned int bit, unsigned int 16 bit,
unsigned int 32 bit......) second the detailed lists of the used
protocol.
Although java it has various types primiti to you, they are with the
sign. How can I solve my problem?

The method that I use, gives back a Object to me.
I must packet this values in a message with a
structure the whose
fields have different types (unsigned int bit,
unsigned int 16 bit,
unsigned int 32 bit......) second the detailed lists
of the used
protocol.
Although java it has various types primiti to you,
they are with the
sign. How can I solve my problem?You cannot have them unsigned in Java.

Similar Messages

About unsigned types

I find that there are no unsigned types in Java, and I wonder why it does not provide
any unsigned types.
Now I am reading a file generated by C programs, and some of them may return negative
bytes rather than positive.
What I have done is to do some convertion like this
int data = ((byte)signedByte+256)%256I wonder if this is a stupid way to get the right data. Any suggestions are appreciated!

hi paulcw
I tried FileInputStream, but it still returns negative
value.Well, it returns a -1 at end of input, but otherwise it only returns positive numbers. At least that's what happened when I tested it. And not only that, but it makes no sense for it to return any negative numbers for the bytes it reads, because if it did, using -1 as an end-of-input indicator wouldn't work.

Why is there no unsigned type is java?

Just wondering? Why no unsigned int or unsigned long? I have often used these in the past but java requires me to do some clever stuff to get over the limitation.

i found this on the net somewhere. it doesn't mention anything about java but it does seem to fit the typical "don't include anything that can be confusing or misunderstood" mold that java utilizes:
"One problem is that unsigned types tend to decrease your
ability to detect common programming errors. Another is that
they often increase the likelihood that clients of your classes
will use the classes incorrectly.
Consider first error detection. Suppose a programmer defines
an Array object as follows:
int f(); // f and g are functions that return
int g(); // ints; what they do is unimportant
Array<double> a(f()-g()); // array size is f()-g()
There�s nothing wrong with this definition for a, except for the
possibility that the programmer writing it made an error. Instead
of the size of the array being f()-g(), perhaps it
should have been g()-f(). Or maybe it should have been
f()+g(). Or possibly it should have been f()-g()+1; off-byone
errors are certainly common enough. Heck, it�s even possible
that f()-g() is correct, but f() or g() is returning a
bad value. Any of these scenarios could lead to the Array
constructor being passed a size that was less than zero. As
the author of the Array class, there�s no way you can keep
clients from making mistakes such as these, but you can do
the next best thing: you can detect such errors and act on
them.
Well, actually, maybe you can�t. You can�t if you declared Array�s
constructor to take an unsigned value, because if a
negative number is passed to a function as an unsigned, the
number seen by the function isn�t negative at all. Instead, it�s
a very large positive number. As a result, you�d have no way
within the Array constructor of distinguishing between a
large, but valid, positive size value and a large, but invalid,
positive size value arising from passing in a negative number.
Hence, you�d be unable to detect programming errors that result
in negative array sizes being requested. Because such errors
are not uncommon, this makes your class easy to use
incorrectly."

Unsigned types in java

hi there,
i was wondering if there is any way to handle unsigned int in java. im making some byte processing and i have a "switch case" statement like below
so when it comes at 0x80 it does not enter the case because it converts it as -1.
im using java 1.7
ByteBuffer record;
pkgId = record.get();
switch ((int) pkgId) {
case 0x75:
break; /* 117 */
case 0x7D:
break; /* 125 */
case 0x80:
break; /* 128 */
case 0x82:
break; /* 130 */
case 0x86:
break; /* 134 */
case 0x87:
break; /* 135 */
}

user8999602 wrote:
hi there,
i was wondering if there is any way to handle unsigned int in java.Use a long.
im making some byte processing and i have a "switch case" statement like below
so when it comes at 0x80 it does not enter the case because it converts it as -1.
im using java 1.7
ByteBuffer record;
pkgId = record.get();
switch ((int) pkgId) {
case 0x75:
break; /* 117 */
case 0x7D:
break; /* 125 */
case 0x80:
break; /* 128 */
case 0x82:
break; /* 130 */
case 0x86:
break; /* 134 */
case 0x87:
break; /* 135 */
}Looks more like you want an unsigned byte. The usual approach to that is to use an int, but you need to mask it. The byte 0x80 has the value -128, so when you simply cast to an int, it sign extends it, and you get 0xFFFFFF80, which is an int value of -128.
int pkgIdInt = pkgId & 0xFF;
switch (pkgIdInt);Alternatively, you could just cast each case value to byte, but that's too cluttered for my taste.

Unsigned data types in Java

I know this is beating an old dead horse, but I find it frustrating that Java does not support unsigned types. I frequently work with binary file formats that store data in unsigned types. In Java there is no easy way to work with these files. For example, if the file has unsigned longs it is a problem. Also, if the file has unsigned ints, a very common occurrence, I have to "upcast" those numbers into longs. This is expensive from a time and space point of view since data files from satellites can be hundreds of megabytes or gigabytes in size and I have to double them in size just to capture the final bit. It is also inefficient to process these files because now I am using longs (64-bits) on systems that are usually optimized for 32-bits which means processing code takes a big performance hit.
Also, there is simple confusion. For example, if I provide data from a file to a user and they see "long" where they know they data is an int they start asking questions and I have to start explaining why it is a long instead of an int. Scientists don't like data to be "translated" for integrity reasons so I have make these long explanations how upconverting to a long is not really a translation, etc. It just creates a lot of confusion and problems.
Also, look at from a developer point of view. The developer has a spec in front of him listing the data types and is now reading the corresponding java class where the data gets loaded--all the data types are different because of the upconverting--it creates confusion.
Is there any hope of having unsigned types or we all condemned to a lifetime of upconverting?

JohnChamberlain wrote:
I thought it was obvious that you need to upconvert unsigned values because otherwise the number will be wrong if the sign bit is set.No. A 32-bit scalar with the high bit set is still correct (bit-for-bit). You only get problems if you perform arithmetic, right-shift or widening-conversion on it, or make a decimal String representation.
For example, lets say the file has an unsigned int (uint32) value of 0xF1234567 which in decimal is 4,045,620,583. This is a positive number. If you load this value into a Java int value it will be interpreted as the negative number -249,346,713.For a given value of "interpreted"; Integer.toHexString(0xF1234567) produces the expected result.
Further example: if you load a file containing uint32 values into Java ints and then average all the values you might come out with a negative number. Obviously this is impossible because the file contains only positive numbers so the average of those numbers cannot be negative.Obviously if you need to do this on a number of large 32-bit scalars you need the sum scalar to be 64-bit which means you can mask your way out of any issues when you perform the widening conversion.
   int[] x = { 0xF1234567, 0xF1234565, 0xF1234557 };
   long sum = 0L;
   for(int i=0;i<x.length;++i) { sum += 0xffffffffL & x; }
int average = (int)(sum/x.length); // average is now "correct" (bit-for-bit)
Maybe it wasn't clear that I need to not only load the values but use them.You did fail to mention that.
The files I load get passed on to other applications where the values get used and obviously that includes doing calculations on them so the values have to be correct. I cannot load a bunch of UInt32s into Java ints and say "pretend they are positive numbers".I get the impression you are not really interested in finding solution.
It can be releasing to have a whinge but don't let it distract you from thinking outside the box.
I think part of the problem here is that Java programmers do not have to work with binary files or binary protocols so they do not appreciate that doing this has serious problems in Java.I have done binary protocols. Not having unsigned scalars was never a problem.
For example, take unsigned longs. If you are working with a binary source that has these you have no alternative except to use the BigInteger package and convert every value into an object, an incredibly painful and CPU-intensive operation if you dealing with files with gigabytes of data.You might want to consider alternatives, like
unsigned right-shifting ('>>>') the incoming values for 64-bit scalar fields where dividing by 2 would be acceptable,
etc.

Unsigned data types

I have been using java for many years and never really needed this (which is probably why it's not in java by default), but I am porting a C++ library to java and the C++ code uses quite a bit of WORD (16 bit unsigned) and DWORDs (32 bit unsigned) and a great amout of shifting.
This is kind of a lame question, but I can't get it to work and I think it is due to the uncontrolable sign bit - does anyone have any resources that can point me in the right direction? Everything on the web just talks about java primitive data type - which I know already - but there is little about using unsigned types or how to port them. Links, books, whatever.
The project is to get a windows library to work on linux (any everything else) - I have ported it into a gcc C++ and will do JNI if it gets down to it, but I would like to get a native java class going. -- I can't post the code because it's NDAed :(
Any info, links, books, tips, anything is highly welcome
Thank you much,
Rob

You don't understand my concern (or I misunderstand
you). A char solution for the 16 bit unsigned type
(word) is great, but if you're gonna write methods to
shift a 32 bit dword as a long (ignoring the sign
bit), why not use that for the 16 bit version as well?I agree, promoting from 16->32 bits or 32-->64 bits sounds like a temporary solution. For "unsigned int"
I'd just use int and shift with >>> and handle comparisons with either promotion to long or a case analysis
on sign, which ever works better.
Let me add, as an old C/C++ programmer I'm glad >99% of the time that Java doesn't have the
plethora of unsigned types of C/C++ (not to method the ambiguity of 'char' in those languages!).
And I don't miss those languages dubious promotion rules. Every C book has the puzzler:
unsigned u = 1;
if (u < -1) {
//always true!

Where to find topics on unsigned variables?

One example is this type ones:
byte etyb = -1 ;
int johns = 255& etyb ;
int skirt = etyb &255 ;
long trousers = johns != skirt ? (short) skirt ++ : (long) johns | --etyb << 1;
\r\n\r\n :)

Java has a single unsigned primitive type, char.
The two uses for unsigned types (AFAIK) are to store larger numbers without incurring storage overheads, or to perform bit operations on.
As for the former, there are very few situtations nowadays in which storing an extra 4 bytes for a value is unacceptable.
As for the latter, it can be seen from the example given that bit operations can be performed normally with signed primitives if you are careful. Know the difference between >> and >>> before proceeding.
is an interesting operator... rather than create unsigned types, Java has chosen to introduce an unsigned operator :-)Having said all that, I don't actually know any topics on unsigned variable types. Perhaps searching the forums for 'unsigned', or the internet for 'java unsigned' or 'java bit operations'. Then ignore hits for unsigned applets :-)
-T

WHY NOT UNSIGNED INT

Hi
In java int or float or double type are signed type
Why not unsigned

It was a design decision not to include unsigned integral types in Java.
Java's designers might have judged that the difficulties and complicity arising from having signed and unsigned types overweigh the benefits in Java.

Unsigned integer problem

Hi,
I have a problem of converting a CRand32 function from C to Java which was originally from IDA decompiler.
There's one thing that's troubling me for quite a long time which is the lack of unsigned types, I could not do operations such as byte shifting correctly and the end result I get is sometimes a negative number or larger than 4billion.
This CRand function should only generate 0 ~ 4billion.
Can anyone enlighten me in this? As it's the first time I am doing such things.
Here's the code I have from direct translation from C to Java :
    private transient long seed1, seed2, seed3; // In the code this is an unsigned int_32
    public final long CRand32__Random() {
     // assume the seed is already an unsigned long..
     seed1 = ((seed1 & 0xFFFFFFFE) << 12) ^
          (((seed1 << 13) ^ seed1) >> 19);
     seed2 = ((seed2 & 0xFFFFFFF8) << 4) ^
          (((seed2 << 2) ^ seed2) >> 25);
     seed3 = ((seed3 & 0xFFFFFFF0) << 17) ^
          (((seed3 << 3) ^ seed3) >> 11);
     return (seed1 ^ seed2 ^ seed3);
    }Thanks,
Edited by: LightPepsi on May 30, 2010 11:40 PM
Edited by: LightPepsi on May 30, 2010 11:40 PM

LightPepsi wrote:
That was the first thing which comes to my mind by changing >> to >>>, however the numbers generated are usually not within the range of an unsigned integer.
It can be sometimes a negative number or larger than 4 billion and thus making the randomizer inaccurate.One possibility is to use ints for the internal shifts, but create a long as
long unsignedValue = intValue & 0xFFFFFFFFL;for returning the number and possibly for any internal comparisons you need to make.
Winston

Parsing binary file- unsigned longs

Hello everyone.
I'm currently trying to write a quick parser for a binary file format (ASF). However, java's handling of bit shifting and lack of unsigned types is driving me completely mad.
How can I represent an unsigned long?
How can I set the bits for it anyway? It seems that the shift operator can't shift more than an int's worth (it just loops around and starts adding to the other bits- weird).
Thanks in advance.
Simon

ejp wrote:
But why in the world does the following code also do nothing?
long x = 45 << 32;
Try long x = 45L << 32;
The answer appears to be that java uses ints to represent all constants, but this presents some serious problems- namely- how on earth do you get a number bigger than an int into a long?With 'L'. Same as in C or C++. In Visual Basic it's '&'. There's generally something.Where did that come from? Why have I never seen anything like that before?
If I do long x = 0x7FFFFFFF; all is well, but if I do long x = 0x80000000; I get FFFFFFFF80000000, which isn't what I asked for.Actually it is exactly what you asked for. You've overlooked several facts: (i) Java longs are 64 bits; (ii) you specified a negative 32-bit constant; (iii) the rules of every programming language I can think of provide for sign-extension when going from a shorter to a longer type.Right. It makes sense now that I know how to specify long constants.
As someone pointed out signed/unsigned is actually the same, so long as you interpret it correctly. So to avoid the total stupidity of using twice as much memory for everything I've decided that I am actually going to use the correct types.They're not the correct types. As I pointed out in an earlier post, your 'unsigned longs' must be coming from C or C++ where they are generally 32 bits, so using a 64-bit Java long is incorrect.Where they came from doesn't matter. The spec doesn't say it's a "long"- it says that this particular value is 64bit, and that all values are unsigned. So I do need a Java long.
WHY IN THE WORLD IS JAVA "INTELLIGENT" WHEN DOING THINGS BITWISE? WHICH BRAIN DEAD IDIOT THOUGHT THAT UP? That is broken and is asking for trouble.It is you who is asking for trouble here. The rules of Java are consistent and in conformity with the practice in other programming languages. You've just overlooked several relevant facts.I think I've worked out where I was going wrong here. When doing something like
int i;
long x;
x = x | i;The i is converted to a long before the bitwise operation, so it's not the bitwise operation that's the problem, it's the conversion between int and long?
It's not Java whose stupidity is the issue here ;-)That wouldn't surprise me.
Thanks.

Logical right shift ( ) operator

Hi,
I suspect a bug in the logical right shift operator >>> (as opposed to the arithmetic right shift >>).
The documentation says "0-s will be shifted from the left". It is not the case.
byte b = -128; // this means 0x80 in hex notation
byte b1 = (byte)(b >>> 4);I would expect b1 = 0x8 (0-s shifted in from the left) but the result is
b1 = 0xF8 instead, as if I had used the >> operator. The sign bit was shifted in from the left instead of 0-s.
Of course, there is a workaround:
byte b1 = (byte)((b >>> 4) & 0x0F); which is the same operation as using >>
If this is the case, what is the purpose of using >>> instead of >> ?
Anyway, the ONLY thing that frustrates me in the Java language that it does not support unsigned integers. It would be important for embedded systems where unsigned numbers are used more frequently.
Any suggestions?
Thank you,
Frank

sabre150:
It depends on the size of processor you use. The Java program runs on a 32- or 64-bit processor, so there is no problem promoting from byte to short or int. But I am talking to an 8-bit processor over a network. So I get a byte stream that has to be converted to numbers here on the Java side. The data types are various: byte or short, even sometimes two 4-bit nibbles (here comes the >>> operator), signed or unsigned. If I get a two-byte sequence, I have to convert it to a short, signed or unsigned. That means in Java promoting the byte to int, shift left the high byte, OR the low byte then cast it back to short if signed, or mask with 0xFFFF if unsigned. The resulting int can be converted to string in the usual way. With distinguished signed and unsigned types, this would be done by the compiler. But I come from the Assembler (and then Pascal/Delphi) world, so it is not a big problem for me.
I agree that this feature is used very rarely, I already wrote the conversion routines, so why bother? As a newcomer to Java (after struggling with C for years, I love it), I just wanted to see whether other people have a better and more efficient idea.
Thank you all for your replies!
Frank

Compile some Pro*c

Hello,
I try to compile some Proc*c but I receiving the following errors:
stgorl80.pc
stgorl80.o(.text+0x8db): In function `daemonize':
: undefined reference to `errno'
collect2: ld returned 1 exit status
make: *** [stgorl80] Error 1
COMPILE_ERROR IN stgorl80.pc
stgorl85.pc
stgorl85.o(.text+0x9e3): In function `daemonize':
: undefined reference to `errno'
collect2: ld returned 1 exit status
make: *** [stgorl85] Error 1
COMPILE_ERROR IN stgorl85.pc
stngtp90.pc
stngtp90.o(.text+0x944): In function `process_ex_later':
: undefined reference to `errno'
stngtp90.o(.text+0xc7d): In function `process_ex_later':
: undefined reference to `errno'
stngtp90.o(.text+0xd10): In function `process_ex_later':
: undefined reference to `errno'
collect2: ld returned 1 exit status
make: *** [stngtp90] Error 1
COMPILE_ERROR IN stngtp90.pc
stscap10.pc
stscap10.c: In function `open_all_ports':
stscap10.c:1998: warning: large integer implicitly truncated to unsigned type
stscap10.c: At top level:
stscap10.c:2453: warning: `State_init' initialized and declared `extern'
stscap10.c:2521: warning: `State_append1' initialized and declared `extern'
stscap10.c:2597: warning: `State_append2' initialized and declared `extern'
stscap10.c:2656: warning: `State_delete' initialized and declared `extern'
stscap10.c:2682: warning: `State_close' initialized and declared `extern'
stscap10.o(.text+0x1b8e): In function `sys_err':
: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead
stscap10.o(.text+0x1b82): In function `sys_err':
: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead
stscap10.o(.text+0x1b58): In function `sys_err':
: undefined reference to `errno'
stscap10.o(.text+0x1b74): In function `sys_err':
: undefined reference to `errno'
stscap10.o(.text+0x1b7c): In function `sys_err':
: undefined reference to `errno'
collect2: ld returned 1 exit status
make: *** [stscap10] Error 1
COMPILE_ERROR IN stscap10.pc
sttilp10.pc
make: *** [sttilp10] Error 1
COMPILE_ERROR IN sttilp10.pc
Can anyone help me?
Many thanks,
Carlos

I had exactly the same problem with the PCC-F-NOERRFILE error.
I think that my oracle installation didn't go completely
smoothly and that's why certain files did not seem to be
properly installed, but here's what I did to get past the
error:
Go to the directory where your oracle distribution is before
it was installed. That is /usr/prod/oracle on my system, and
it's probably different on yours. Look at the message files in
precomp/mesg. Chances are, these files were not completely
installed during the installation. I copied them by hand into
the target directory of my installatio, which is
/usr/u01/oracle/product/8.0.5/precomp/mesg on my system. Now I
am able to run proc without any problem.
Hope that helps.
Simon
Matt Miller (guest) wrote:
: I have just finished installing 8.0.5.1 on RedHat 5.2 and
setting
: up a database. Everything works well after installing the
: glibcpatch. Now I want to compile some Pro*C programs but proc
is
: not found in the $ORACLE_HOME/bin directory. The oracle
install
: program, orainst, says that it was installed. The
: $ORACLE_HOME/precomp directory looks OK except it was missing
: the
: /admin/pcscfg.cfg file which I have now created according to
: instructions I found in the 8.0.5 FAQ. I found the proc
: executable in the distribution directory and copied it into my
: bin directory.
: When I run it, I get the following message:
: "PCC-F-NOERRFILE, unable to open error message file, facility
: PR2"
: Can anyone help me get the Pro*C installed correctly or am I
: just not using it correctly?
: I am not experienced with Pro*C, but very familiar with Oracle
: Server.
: Thanks in advance
: matt
null

NewDES implementation in Java

Hi,
I�d like to do a correct implementation of NewDES algorithm in Java.
Any ideas?
Thanks a lot.

Thanks for URL, but I can�t resolve the exclusive xor
between unsigned char (Java don�t have unsigned type
of 8 bits). Can you help me?Use bytes not chars. Then, it is normal to use something like
byte a = ...
byte b = ...
byte c = (byte)( a ^ b);
Messy but it works.
If you need to do shifting you should mask values to the desired bit range before doing any assignment.

Maximum number of key/value pairs in btree or hash database

It's not clear to me from the documentation what the limit is on the number of key/value pairs in a Btree or hash database. The documentation on logical record numbers says that the db_recno_t type is a 32-bit unsigned type, "which limits the number of logical records in a Queue or Recno database, and the maximum logical record which may be directly retrieved from a Btree database, to 4,294,967,295". What does "directly retrieved" mean in this sentence? Does this mean that Btree is limited to 4,294,967,295 key/vaue pairs? If so, is this also the limit for a hash database?

Hi mcgarvek,
In case of Queue, Recno and Btree configured for logical record numbers - you can do that by setting DB_RECNUM flag: http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/db_set_flags.html#DB_RECNUM , the maximum number of records is 4,294,967,295 and after that limit, the next record will be inserted as record number 1.
In case of Hash and Btree, the maximum database size depends on the page size selected by the application. Berkeley DB stores database file page numbers as unsigned 32-bit numbers and database file page sizes as unsigned 16-bit numbers. Using the maximum database page size of 65536, this results in a maximum database file size of 248 (256 terabytes).
Database limits: http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_misc/dbsizes.html
Logical record numbers: http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am_conf/logrec.html
Regards,
Bogdan Coman

Illegal register: "icc" : syntax error with Sun C 5.8 compiler

I wanted to compile my C file with compiler option "cc -c -Xc -mt -fast -xarch=amd64" on Solaris 10 amd64 machine but it failed with following error -
Assembler: abc.c
"/tmp/GAAOBain6", line 819 : Illegal register: "icc"
"/tmp/GAAOBain6", line 819 : Syntax error
Near line: " orq %icc,%r8 ;/ line : 210"
"/tmp/GAAOBain6", line 852 : Illegal register: "icc"
"/tmp/GAAOBain6", line 852 : Syntax error
Near line: " movzwq %icc,%r9 ;/ line : 215"
cc: ube failed for abc.c
*** Error code 2
I am using following sun C compiler -
/SS11/SUNWspro/bin/cc -V
cc: Sun C 5.8 Patch 121016-02 2006/03/31
Do anybody has idea about this issue?
Thanks
Sgupta

Thanks Boris for your help.
My abc.c file is following -
struct struct_1 {
unsigned type:8;
unsigned level:5;
unsigned seen:1;
unsigned pad:2;
unsigned length:16;
void sample (unsigned char type)
struct struct_1 *q;
/*** Allocate and assign pBody here **/
q->type = type;
q->length = type;
==========================================
compiling this file with following option gives the error in Sol-10 amd64 -
/SS11/SUNWspro/bin/cc -c -Xc -mt -fast -xarch=amd64 abc.c
But compiling without "-fast" options work fine.
Thanks
Sgupta

Unsigned type

Similar Messages

Maybe you are looking for