Path: utzoo!attcan!uunet!unisoft!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: serious code generation bug in Lightspeed C
Message-ID: <6315@hoptoad.uucp>
Date: 15 Jan 89 12:18:10 GMT
References: <6275@hoptoad.uucp> <1676@helios.ee.lbl.gov>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 37

OK, I stand corrected.  The evaluation order is undefined.  Thanks to
those who pointed this out, and particularly to those who pointed out
what a weird and frustrating problem it is regardless.

On a couple of specific points:

It is silly to say that this is a well documented problem.  I've read
three drafts of Inside Mac, starting with the loose-leaf binder edition
unfathomable aeons ago, and that an assignment could require locking
has never been explicitly mentioned.  Dennis Cohen claims that it was
mentioned in a comment in one of the earliest programming examples on
the Mac.  This is not documentation, this is source code, and I hope
Apple doesn't become as bad as Sun at understanding the difference.
This is not a documented problem at all, much less well documented.
Both Apple and compiler developers should document it; neither does.

In article <1676@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard)
writes:
>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.

True, the result from NewPtr (or whatever the value of the RHS may be)
has to be stored if the RHS is evaluated first.  However, if the LHS is
evaluated first, then the address for the lvalue has to be stored
instead.  The cost of storing one is precisely the same as the cost of
storing the other.  Efficiency is a bogus rationale.

Defensive?  Not me, buddy!  Maybe YOU'RE defensive, but I'M not! :-)
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"There are no Famous People on the net.  Only some of us with bigger mouths
 than others."  -- Dan'l Danehy-Oakes, The Roach