limitations of casts, pointer and function declarartions...

[Doug Gwyn <gwyn>]

> 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.