Path: utzoo!attcan!uunet!husc6!rutgers!ucsd!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSC 3.0 Boolean Bug/Feature
Message-ID: <25507@ucbvax.BERKELEY.EDU>
Date: 7 Aug 88 00:29:54 GMT
References: <3653@bnrmtv.UUCP> <586@mailrus.cc.umich.edu> <25467@ucbvax.BERKELEY.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Distribution: na
Organization: School of Education, UC-Berkeley
Lines: 33

In article <25467@ucbvax.BERKELEY.EDU> I write:
>LightSpeed C 3.0 compiles a slightly different language than the older
>LightSpeed Cs, and it can get you into trouble. You will have no trouble
>----- file 2 -----
>#include <MacTypes.h>
>Boolean Oster(){ return FALSE; }
>-------------------

correction. The above Oster() function actually clears all of the function
return register.  To see the bug, use the following file2:

----- file 2 -----
#include <MacTypes.h>	/*actually redundant, this line included for clarity*/
Boolean Oster(){
	Boolean data[2];

	data[0] = FALSE;
	return data[0];
}
---------------------

If you single step through the program, you'll watch LSC move the result
of Oster into D0 with a MOVE.B instruction, return, and then test the
result with a TST.W instruction. If you seed D0 with garbage before the
call to Oster(), the program will print "True" even though "False" was
returned.

I don't think LSC is broken, I justthink there is somethinbg in the
proposed ANSI standard that mandates this unfortunate behavior.

--- David Phillip Oster            --When you asked me to live in sin with you
Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu