Function-returned structures

[guy at gorodish.UUCP]

>4.3BSD won't take
>
>	f().x,

Because there's a bug in the compiler.  The System V PCC has changes
that fix this, but break other things.

The trouble here is that there is a routine "notlval" that returns
TRUE for structure assignment and structure call nodes and for nodes
of type "array" or "function", FALSE for other NAME, OREG, and REG
nodes, and TRUE for everything else.  However, there are some nodes
that are not lvalues but *are* legitimate structure references,
namely the aforementioned structure assignment and structure call
nodes.

This routine is used by the code in "cgram.y" to test whether
the LHS of the "." operator is a legitimate structure reference.
This means that "f()" will not be considered a legitimate structure
reference.

The "fix" in the System V PCC was to change "notlval" to consider
structure assignments and structure calls to be lvalues.  This fixes
this problem, but allows you to write things like

	f() = x;

which is not too cool.

The correct fix is to add a new routine "notstref" that returns FALSE
for the structure assignment and structure call nodes, and have
"notlval" return TRUE for those nodes (both routines return the same
values for other types of nodes), and use that routine instead of
"notlval" in the test in "cgram.y".

>but amazingly it will take
>	
>	( &f() ) -> x

This one is harder to fix; I haven't looked at it in painful detail,
but I think the problem is that by the time it gets around to
checking these things it's already decided that "f()" is really a
"dereference" operator on top of a "pointer to structure" node, and
of *course* you can take the address of *that*.

>Perhaps if this is really too hard to check in a compiler
>(is this what you are saying?),

No, I think he's saying it's too messy to *define* what is valid and
what isn't.  If you allow

	f().a

when "a" is *not* an array, what happens if it is?  Sticking in an
"except if it's an array" clause is a bit messy.  This isn't an
implementation issue (although forbidding this would be hard in PCC -
as would forbidding

	&(f().a)

if "a" is not an array), it's a language definition issue.