Path: utzoo!attcan!uunet!lll-winken!claris!drc
From: drc@claris.com (Dennis Cohen)
Newsgroups: comp.sys.mac.programmer
Subject: Re: serious code generation bug in Lightspeed C
Message-ID: <8030@claris.com>
Date: 12 Jan 89 22:30:22 GMT
References: <6275@hoptoad.uucp>
Reply-To: drc@claris.com (Dennis Cohen)
Organization: Claris Corporation, Mountain View CA
Lines: 27

In article <6275@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
>
>This is pretty amazing, even for a compiler like Think's that
>deliberately produces low-budget, non-optimized code.  There is a
>work-around, assigning the result of NewPtr into an intermediate
>variable and then assigning it to the lvalue, but it is unwieldy, and
>it is difficult to spot all places where this compiler bug could bite.

I couldn't let this pass.  While I agree that it is undesirable behavior,
it is unfair to single out THINK/Symantec on this one.  This same "bug"
exists in MPW C, MPW Pascal, Turbo Pascal, TML Pascal, and LightSpeed
Pascal -- in fact, in every Mac compiler I've used.  This is another
example of why you are told to HLock your handles before doing these
sorts of things (that move memory).  The earliest programming examples
on the Mac listed the lvalue problem as a place where you HLock or use
a temporary.  It isn't really a bug since the code is supposed to be
compatible with MPW and you don't really want different behavior for such
a thing.

To sum up -- this isn't a BUG, it is just a very unfortunate and well-
documented FEATURE.


Dennis Cohen
Claris Corp.
------------
Disclaimer:  Any opinions expressed above are _MINE_!