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>