rjd@cs.brown.edu (Rob Demillo) (03/29/90)
I have a bit (excuse the pun) of a problem I'd like some
help with.
I am bringing some C code that I wrote over from a UNIX system which
is trying to do the following:
set up bit fields within a 4 byte word.
union that word to a 4 byte char string and a long.
Essentially, the structure mappings look like:
struct phred
{
unsigned long a:20;
unsigned long b:11;
unsigned long c:1;
} ;
union {
struct phred ieee;
char string[4];
float floater;
} float_guy;
This way, when I read a floating point number into float_guy.floater,
I can get at the word in a variety of different chunks...
Now, I've ported this code to a couple of machines, and it works
fine, but, unfortunately...Laser C does not allow bit field assignments
on anything other than unsigned ints, so it chokes on by
unsigned long a:20, etc...
...looking at the K&R language description, it states as one of
the caviats that bit fields should not cross int boundaries, and
an int in Laser C is 2 bytes long.
So, am I screwed, or can you folks suggest an alternative to what
I want to do? (I *hope* so, otherwise I'm in for a *major* rewrite of
my code, and what I'll be left with is an ST-specific peice of
C code...I hate that.
So, any suggestions?
Thanks in advance.....
-- Rob
- Rob DeMillo | Internet: rjd@brown.cs.edu
Brown University | Also Internet: demillo@juliet.ll.mit.edu
Planetary Science Group | Reality: 401-273-0804 (home)
"I say you *are* the Messiah, Lord! And I ought to know, I've followed a few!"swklassen@tiger.waterloo.edu (Steven W. Klassen) (03/30/90)
In article <34368@brunix.UUCP> rjd@cs.brown.edu (Rob Demillo) writes: > >Now, I've ported this code to a couple of machines, and it works >fine, but, unfortunately...Laser C does not allow bit field assignments >on anything other than unsigned ints, so it chokes on by >unsigned long a:20, etc... > >...looking at the K&R language description, it states as one of >the caviats that bit fields should not cross int boundaries, and >an int in Laser C is 2 bytes long. In K&R C, bit fields are only guaranteed for the type unsigned (i.e., not unsigned short or unsigned long, just unsigned). Compilers which allow other types are extensions to the standard. >So, am I screwed, or can you folks suggest an alternative to what >I want to do? (I *hope* so, otherwise I'm in for a *major* rewrite of >my code, and what I'll be left with is an ST-specific peice of >C code...I hate that. In their book, K&R comment that the way a compiler deals with bit fields can vary from compiler to compiler. Specifically, it may start listing the bit fields either from the left or from the right. Hence bit fields are inherently machine specific. They are normally used to access some sort of machine specific hardware. The only way that you can GUARANTEE portability would be to use an unsigned long (integer, NOT bit field) and use bit masks and the bit operators to manipulate your data. (Granted, this isn't as simple as bit fields are but it is more likely to be portable.) Steven W. Klassen +-----------------------------+ Computer Science Major | Support the poor...buy fur! | University of Waterloo +-----------------------------+