[comp.lang.ada] problem with using bitfields

rrw@cci632.UUCP (02/15/87)

I'm having a problem with getting bitfields to work. I think that
I'm doing what the LRM (13.4) says to do, but the compiler refuses
to accept it. Can anybody see what the problem is?

Here's the code:
package FOOBAR is

type DARK_VECTOR_TYPE is
	record
	vector:	POSITIVE range 0 .. 2#1111111#;
	parity:	POSITIVE range 0 .. 1;
	end record;

for DARK_VECTOR_TYPE use
	record	at mod 8;
	vector	at 0	range 0 .. 6;
----^A                                                                       ###
--### A:error: LRM 13.4(7): not enough space allocated for field
	parity	at 0 	range 7 .. 7;
----^A                                                                       ###
--### A:error: LRM 13.4(7): not enough space allocated for field
	end record;

for DARK_VECTOR_TYPE'SIZE use 8;
------------------------------^A                                             ###
--### A:error: LRM 13.2(5): specified size is too small for type

end FOOBAR;

If I increase the space allotted for each field to 32, it works.
This will not do for my project, though.

Any help would be greatly appreciated.

			Thanks,
				Rick Wessman
				..!seismo!rochester!cci632!rrw

kinder@omepd.UUCP (02/17/87)

In message 148, Rick writes that a compiler complained about a record field 
of type "POSITIVE range 0..1" when a rep clause tries to  pack  this  field
into one bit (and similarly when a field of type "POSITIVE range 0..2**6-1" 
is packed into 6 bits).  

Since the type POSITIVE is a subtype of INTEGER, the compiler  is  probably
complaining  because  you  haven't  left  room  for  a "sign" bit.  In many
architectures, there is a difference between integer (signed)  and  ordinal
(unsigned)  operations  (such  as,  whether arithmetic overflow is raised).
The compiler may have decided that since you used a subtype of  an  integer
type,  you  intend for integer-like behavior, and because of this, you need
to leave room for one more bit for the sign, (even  though  your  subtype's
range can have no negative values).  

The easiest way to determine this compiler behavior is to try a  rep-clause
to  pack the fields into 2 bits and 7 bits respectively.  There may also be
a pre-defined numeric  type  available  (perhaps  in  System)  that  is  an
unsigned numeric type that you can use and would not require a sign bit.