bit-field pointers / arrays

Wayne Throop throopw at dg_rtp.UUCP
Tue Dec 16 07:33:28 AEST 1986


> stuart at bms-at.UUCP (Stuart D. Gathman)
> It  has  been  said  that  bit-field  arrays  are   intrinsically
> impossible in 'C' because there can be no pointers to bit-fields.

Waitaminut!  Who said that?  I (and the others I've seen) said that
bit-field arrays are impossible in C as C is currently defined, and
pointed out that there are several ways that this notion conflicts with
the current definition of C.  Naturally, if pointers to 1-bit-aligned
chunks of storage are allowed, or if the definition of array
subscripting in terms of pointer arithmetic is changed (and of course,
the syntax of general declarators changed also), then arrays of
bit-fields are possible.

I do wonder about Stuart's proposed syntax for declaring pointers to
bit-fields:

>         unsigned *bitptr:1

How does the bitsize qualifier fit into the general declarator syntax,
prescedence-wise?  If it behaves like the other suffix declarator, [],
then what we have here is a one-bit pointer to an unsigned and ought
really to be (*bitptr):1, whereas the next example:

>         unsigned bitarr[5000]:1

is more reasonable, an array of one-bit unsigned integers.

On the other hand, perhaps Stuart meant the :N to come at the end of the
declaration and refer to the integer type involved, however distant that
is to the :N syntactically and structurally.  I suppose that works, sort
of, and is analogous to how it happens in struct definitions.

I emphasize: I don't say that defining some C-like language with these
features is bad.  It is just far, far outside the scope of the current
X3J11 effort.

--
Like punning, programming is a play on words.
                                --- Alan J. Perlis
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw



More information about the Comp.lang.c mailing list