Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!decwrl!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: lvalues
Message-ID: <11795@sun.uucp>
Date: Wed, 21-Jan-87 14:27:49 EST
Article-I.D.: sun.11795
Posted: Wed Jan 21 14:27:49 1987
Date-Received: Thu, 22-Jan-87 02:55:25 EST
References: <252@merlyn.UUCP>
Sender: news@sun.uucp
Lines: 20
Summary: Hardware that supports bit addressing and languages that support bit pointers are not inexorably tied together.

> >The expression designating a bit-field cannot be evaluated to yield a
> >context-free representable "value" that can be passed around, stored &c.
> >Hence there is no lvalue of a bit-field.
> 
> This is true of most machines;

This is neither true nor false of any machine.  Machines aren't being
discussed here; C compilers are.  You can have a C compiler that doesn't
support bit-field pointers on a machine that supports bit addressing; you
can have a C compiler that supports bit-field pointers on a machine that
doesn't (this would, of course, be an extended version of C, and you might
have to be careful not to make these extensions in such a way as to render
the implementation nonconforming).

There is no law that requires that implementations on machines that support
bit addressing support bit-field pointers, nor that implementations on
machines that don't support bit addressing not support bit-field pointers.
(One might just as well argue that you can't have "char *" on a
word-addressible machine.)  Consider all the PL/I implementations on
machines not supporting bit addressing.