Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!eecae!cps3xx!rang
From: rang@cpsin3.cps.msu.edu (Anton Rang)
Newsgroups: comp.sys.mac.programmer
Subject: Re: serious code generation bug in Lightspeed C
Message-ID: <1503@cps3xx.UUCP>
Date: 12 Jan 89 18:37:41 GMT
References: <6275@hoptoad.uucp>
Sender: usenet@cps3xx.UUCP
Reply-To: rang@cpswh.cps.msu.edu (Anton Rang)
Organization: Michigan State University, Computer Science Dept.
Lines: 29
In-reply-to: tim@hoptoad.uucp's message of 12 Jan 89 15:02:44 GMT

>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.
>
>For example, suppose you have a relocatable data structure and a handle
>to that structure in "h".  Further suppose that one member of the
>structure referred to by "h" is of type Ptr, called "p".  Then this
>straightforward statement gives an incorrect result:
>
>	(*h)->p = NewPtr(size);

  This isn't a bug, though you could argue that it is undesirable.  As
Apple says in IM, don't write code like this--lock the handle before
you assign into it, then unlock it; alternatively, use a temporary.
  I'm not sure if C specifies whether an lvalue or rvalue should be
evaluated first in an assignment statement.  There are many
ambiguities, for instance:

  *p = f();  /* where f() modifies p */

in which the programmer probably expects *p to be evaluated first.

		Anton

+---------------------------+------------------------+----------------------+
| Anton Rang (grad student) | "VMS Forever!"         | "Do worry...be SAD!" |
| Michigan State University | rang@cpswh.cps.msu.edu |                      |
+---------------------------+------------------------+----------------------+