Path: utzoo!utgpu!watserv1!watdragon!tiger!swklassen From: swklassen@tiger.waterloo.edu (Steven W. Klassen) Newsgroups: comp.sys.atari.st Subject: Re: Help with bit field troubles in Laser C Message-ID: <22652@watdragon.waterloo.edu> Date: 29 Mar 90 16:28:08 GMT References: <34368@brunix.UUCP> Sender: daemon@watdragon.waterloo.edu Organization: University of Waterloo Lines: 35 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 +-----------------------------+