Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.lang.c
Subject: Re: limitations of casts, pointer and function declarartions...
Message-ID: <5505@brl-tgr.ARPA>
Date: Mon, 29-Oct-84 20:51:04 EST
Article-I.D.: brl-tgr.5505
Posted: Mon Oct 29 20:51:04 1984
Date-Received: Wed, 31-Oct-84 01:17:50 EST
References: <120@harvard.ARPA> <5487@brl-tgr.ARPA> <122@harvard.ARPA>
Distribution: net
Organization: Ballistic Research Lab
Lines: 38

> K&R 'defines' an lvalue as an 'expression referring to an object'.
> and an object as a 'manipulable region of storage'. '(char *)x' is a
> perfectly good lvalue: it refers to the object 'x' considered as
> a pointer to a character.

K&R is not at all clear about lvalues.  That shows why we need a good
standards document.

> >> typedef ref *ref;
> 
> I think the semantics of this typedef are clear (and can be defined
> easily). Also, the above typedef is in no way different from the
> structure declaration 'struct foo {foo *ref;};'. FTSO consistency and
> considering its usefulness, I think the above typedef should be
> permitted. (BTW, a struct/union is not a basic type either).

Ok, so I should've said "type-specifier".  There is a big difference
between your typedef, which has indeterminate content (e.g. the compiler
could consistently allocate no storage at all for the type!) and a struct/
union that can contain a pointer to an instance of itself (whether it can
contain a pointer to a not-yet-defined type is a debatable point).  There
is an explicit KLUDGE made in the language rules to permit such structs,
due to their great usefulness in implementing data structures.

> Again, my question is: given the 4.2 cpp and ccom, what is the most
> convenient way (i.e. requiring the least number of typecasts) of
> dealing with the case the 99% of all pointers give another pointer of
> their own kind upon dereferencing?

Your example could be achieved within the rules by using
	typedef struct ref { struct ref *ref; } ref;
since now it is clear how much storage to allocate for one of these beasts.
It is then trivial to write macros to dereference a "ref" etc.:
	#define nextref( refp )	(refp)->ref	/* for pointers */
	#define deref( ref )	(*ref.ref)	/* for values */
The first of these returns an lvalue, the second an rvalue.

The point is, don't fight the language but rather, learn to exploit it.