Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!ames!ucbcad!ucbvax!decvax!mcnc!rti-sel!dg_rtp!throopw From: throopw@dg_rtp.UUCP (Wayne Throop) Newsgroups: comp.lang.c Subject: Re: bit-field pointers / arrays Message-ID: <756@dg_rtp.UUCP> Date: Mon, 15-Dec-86 16:33:28 EST Article-I.D.: dg_rtp.756 Posted: Mon Dec 15 16:33:28 1986 Date-Received: Wed, 17-Dec-86 04:42:47 EST References: <311@bms-at.UUCP> Lines: 41 > stuart@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!mcnc!rti-sel!dg_rtp!throopw