Dealing with unsigned types in file formats.

[Andreas Falley]

Hi, a few years ago I wrote a program in C that did various bits of processing on a wave file. Originally I wanted to use Java but a part of the file format for a 8-bit wave file contains a stucture that is based on various unsigned types:
typedef struct {
ID chunkID;
long chunkSize;
short wFormatTag;
unsigned short wChannels;
unsigned long dwSamplesPerSec;
unsigned long dwAvgBytesPerSec;
unsigned short wBlockAlign;
unsigned short wBitsPerSample;
/* Note: there may be additional fields here, depending upon wFormatTag. */
} FormatChunk;
My questions are these:
How do you deal with such file format constraints in Java?
Is it just that "well, some things are better suited for some languages and others for other languages"?
Why are there no unsigned longs and shorts in Java? Doesn't it make sense for Java to incorporate these, especially as it tries to be so ubiquitous in so many different ways. Even the audio api isn't all that robust since it doesn't allow for 16 bit or larger wave files or surround sound etc.; it seems there are a such a wide range of applications (look at the pro-audio section of any music store) that java is missing out on. I had hoped that in new versions of Java unsigned types would be incorportated. What's up with that?
Thanks in advance!
-Andreas
[ March 19, 2002: Message edited by: Andreas Falley ]

[Michael Morris]

Hi Andreas,
The reason Java doesn't have unsigned integral types is that there not needed (except in one type of shift operator which Java takes care of.)
To paraphrase Dennis Ritchie (the designer of the C language): "Unsigned types are for squeezing one more bit from memory." If you think about it it's no big deal to convert an "unsigned" C type to a Java integral and vice-versa. The only problem is knowing how many bits the C implementation uses (8, 16, 32?) Of course all of Java's primitives are absolutely defined. If you fully understand the file format, you should be able to read in a file with a byte stream and reassemble the bytes into your "home-grown" unsigned types. There is certainly nothing stopping you from making an "UnsignedInt" class with a constructor that knows how to deal with an array of bytes.
Hope this helps
Michael Morris
SCJP

[Peter den Haan]

Your only problems are (possibly) the unsigned longs. All others can be represented by Java data types: if s is an unsigned short contained in a (signed) Java short variable, then (s & 0xffff) is the (signed int) value of s.
If those longs are really 64-bit (they probably are), you can do a couple of things. You can assume that they will never be so large as to become negative, which seems a realistic assumption. Or you represent them as a BigDecimal. It's a bit of a hassle but, hey, I once manipulated larger numbers on an 8-bit CPU, it can all be done.
Also please note that in some contexts signedness is just a matter of interpretation. Adding or subtracting two 2-s complement numbers is the same regardless of whether the numbers are signed or not, and Java doesn't throw an exception upon (signed) arithmetic overflow. Counting (increments and decrements) will still work too.
- Peter