Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!harvard!olson
From: olson@harvard.UUCP
Newsgroups: comp.sys.mac
Subject: Re: Broken compilers
Message-ID: <1087@harvard.UUCP>
Date: Tue, 12-May-87 09:46:14 EDT
Article-I.D.: harvard.1087
Posted: Tue May 12 09:46:14 1987
Date-Received: Thu, 14-May-87 06:53:58 EDT
References: <949@batcomputer.tn.cornell.edu> <746@apple.UUCP> <1953@husc6.UUCP>
Reply-To: olson@endor.UUCP (Eric Olson)
Organization: Aiken Computation Lab Harvard, Cambridge, MA
Lines: 23
Keywords: IMPORTANT WARNING LIGHTSPEED C

In article <1953@husc6.UUCP> stew@endor.UUCP (Stew Rubenstein) writes:
>...
>All programs compiled with LightSpeed C WILL BREAK, GUARANTEED 100%,
>when Apple comes out with a 32 bit operating system for the Mac II or
>future hardware.  This is true of LightSpeed C versions 1.02 and 2.01.
>The problem is that they use a BSET instruction to manipulate Handle
>state flags.  Apple has repeatedly warned Developers (e.g., in Tech
>Note #2, dated January 21, 1986) that this is a no-no.
>...
>

Is this true of the Mac-style support libraries (MacLib) or the unix-style
support libraries, or the code that runs just before main(), or all three,
or WHAT?  This seems very important!  I'm hoping it's only in the unix
libraries, since I don't use them anyway.  This should be a correctable
problem.  Is the code that comes before main() in LSC replaceable by the
end-user (of the compiler)?

How about it, THINK?  What's the scoop?

-Eric
olson@endor.harvard.edu
olson@endor.UUCP