Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!ux1.lbl.gov!beard
From: beard@ux1.lbl.gov (Patrick C Beard)
Newsgroups: comp.sys.mac.programmer
Subject: Re: serious code generation bug in Lightspeed C
Message-ID: <1676@helios.ee.lbl.gov>
Date: 12 Jan 89 20:13:49 GMT
References: <6275@hoptoad.uucp>
Sender: usenet@helios.ee.lbl.gov
Reply-To: beard@ux1.lbl.gov (Patrick C Beard)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 32

In article <6275@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
>There is a serious bug in how Lightspeed C handles the assignment
>operation.  The lvalue is evaluated before the value is computed.  This
>means that assigments to relocatable structure members do not work
>correctly.
>

Not only is this problem not a bug in the compiler, and a bug in the 
programmer, but it would lead to inefficient implementation of the
compiler and inefficient code generation!  No way do I want the 
compiler to know whether or not a lhs has a relocatable object in it.
That would force the compiler to generate a temporary location to
store the result of the NewPtr call, EVERY time I have a relocatable
object in the lhs.  Either the compiler generates the temporary, or 
the programmer does.  And with judicious Locking and unlocking of the
handle in question, a temporary need not be generated.  Therefore
your assertion that the lhs should be evaluated after the rhs is very
misguided.  Depending on the order of evaluation beyond operator precedence
rules leads to very non-portable code.

In fact, the problem is much more general than you think.  You can be
bitten by this bug in Pascals as well.  If you use the WITH statement,
e.g.
	WITH h^ BEGIN
		p := NewPtr(size);	{ put a pointer into a relocatable object. }
	END;

You can have the same problem.  h^ is evaluated at the beginning of the
WITH in most Pascal implementations.  Same problem.

Patrick Beard
Berkeley Systems, Berkeley CA