Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!vrdxhq!bms-at!stuart
From: stuart@bms-at.UUCP
Newsgroups: comp.lang.c
Subject: bit-field pointers / arrays
Message-ID: <311@bms-at.UUCP>
Date: Wed, 10-Dec-86 20:04:34 EST
Article-I.D.: bms-at.311
Posted: Wed Dec 10 20:04:34 1986
Date-Received: Sun, 14-Dec-86 09:26:10 EST
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 45
Keywords: why not?

It  has  been  said  that  bit-field  arrays  are   intrinsically
impossible in 'C' because there can be no pointers to bit-fields.

There is no special reason why there cannot be a type like:

        unsigned *bitptr:1

which would likely be bigger than a 'char *'.  Then we could also
declare:

        unsigned bitarr[5000]:1

or even:

        unsigned pixelarr[640]:4

for a line of EGA pixels.

Bitfield pointers would have wildly different  formats  depending
on the processor, of course.

For 68020, it might be 6 bytes.  An address  followed  by  offset
and  width in each of two bytes.  This would be loaded into three
registers for use with the bit field processor instructions.

Adding and subtracting integers, increment and decrement, all are
straightforward to define.

The problem comes with 'sizeof'.  What is the size of a bit?

1.   My  first  impulse  is  to  disallow  'sizeof'  applied   to
bitfields.  (It is not allowed now anyway.)

2.  Another alternative is to make sizeof char  ==  8,  but  this
would cause problems allocating huge arrays with malloc().

3.  A third approach is to define the size of a  bitfield  to  be
the minimum number of standard sizeof units required to store the
field.  This would allow code such as:

        pixptr = (unsigned *:4) malloc(sizeof (unsigned [640]:4));

"k - a ring of fire resistance (on right hand)"
-- 
Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>