summary: pointers, casts, &c.

[Thomas M. Breuel]

Well, once more, and hopefully for the last time, about the topic
of pointers, casts, &c.:

'(type)x = y;'

As posted before, there are two ways of filling this construct with
meaning.  Either one is easy to achieve by a cast, namely:

*(otherType *)&x = y;
x = (otherType)y;

(in the case of additive assignment operators this becomes more complicated.
If you like to be bored, I'll be happy to send you a few pages on it :-).

>From K&R's 'Syntax Summary' it is clear, though, that 'C' currently
accepts casts only as part of an expression, and expressions can only
be part of an lvalue if preceeded by an asterisk. Given the relative
ease with which either of the above meanings is expressed in 'C', an
extension of the language (:-() appears unnecessary.

'typedef ref *ref;'
'typedef fun *(*fun)();'

K&R defines typedef indeed as a purely syntactical means of introducing
new data types, and 'C' compilers have therefore trouble handling these
expressions. Admittedly, it would probably either require a bad hack or
some major restructuring of a 'C' compiler to make the above work
sensibly.  I maintain, though, that these are sensible type
definitions, and that it is a flaw of the 'C' language not to handle
them (but no programming language is flawless, not even PROLOG).
Again, don't consider this as an outcry for changing the existing 'C'
language ('C' needs BCD, right? :-), but as something to think about when
designing some new and better systems programming language.

'typedef ref *ref;'
'struct foo {struct foo *ref};'

These data types are 'recursive' in the sense that they are the simplest
possible implementation of the corresponding 'truely recursive' data
types. Sorry about my fuzzy terminology, but since 'C' doesn't
have truely recursive data types, there is no possible ambiguity.

					Thomas.
					(breuel at harvard)

PS: The problem I'm having with K&R is that it is neither a good user's
manual, nor a strict definition of either the syntax or semantics of
the 'C' language. But, then, 'C' doesn't have strict syntax or semantics,
as exemplified by the differences among the various available 'correct'
'C' compilers. 

You may not like standard Pascal (as defined by Wirth), and may say that
it isn't good for much else but teaching intro courses in CS, if at all,
but I think that you must admit that it is defined a lot more rigorously,
smoothly, and consistently than 'C'. This is unfortunate.