Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!rutgers!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: bit-field pointers / arrays Message-ID: <5451@brl-smoke.ARPA> Date: Mon, 15-Dec-86 12:09:02 EST Article-I.D.: brl-smok.5451 Posted: Mon Dec 15 12:09:02 1986 Date-Received: Wed, 17-Dec-86 18:50:52 EST References: <311@bms-at.UUCP> <194@haddock.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 22 In article <194@haddock.UUCP> karl@haddock.ISC.COM.UUCP (Karl Heuer) writes: -I think that this would be the best initial step. It would be nice to phase -out the assumption that sizeof(char)==1, but I think that (for this version of -the standard) ANSI had better insist on it, though they may want to mark it as -deprecated. - -But before they can remove this assumption, they have to go through all the -functions that mention (or suggest) "bytes" and decide whether they mean -"char" or "quantum of sizeof". For example, malloc() should probably expect -a bit count (even though it rounds upward for alignment), but what about -fread()? If it expects a bit count (which is what one would expect, given -that its arg type is "size_t"), what happens if you try to fread() one bit? This work has already been done, in document X3J11/86-136R, although that document does not consider the bit in a bit-field as the fundamental storage unit but rather proposes (short char), which may or may not be a single bit as the implementor chooses. A presentation of the whole multi-storage-unit character issue is scheduled for the March 1987 X3J11 meeting. If you have points you want considered in this regard, please send them to me (Gwyn@BRL.MIL), since I'll be making the presentation.