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.