Path: utzoo!attcan!uunet!portal!cup.portal.com!Michael_mkahl_Kahl
From: Michael_mkahl_Kahl@cup.portal.com
Newsgroups: comp.sys.mac.programmer
Subject: Re: Lightspeed C projects
Message-ID: <6980@cup.portal.com>
Date: 30 Jun 88 01:38:07 GMT
References: <1407@its63b.ed.ac.uk> <4710@husc6.harvard.edu> <6879@cup.porta
Organization: The Portal System (TM)
Lines: 17
XPortal-User-Id: 1.1001.4169

>	Any particular reason for using THINK_C instead of the
>more ANSI-acceptable __THINK_C?

No particular reason.  I don't imagine THINK_C will lead to many conflicts.

>Speaking of ANSI-acceptability, can anyone from THINK expand on the changes
>(if any) made to LightspeedC in order to bring it more into ANSI compliance?
>E.g. have prototypes been modified to reflect the new standard?  Have the new
>keywords (const, volatile, etc.) been added?  Anything??

The preprocessor now supports the # and ## operators for string-izing and
token-splicing.  Full ANSI support was delayed in order to get the debugger
out.  However, we do intend to fully conform to the ANSI standard (when it
is finalized), and hope that our customers appreciate the preprocessor
extensions as a step in this direction.

-- Michael Kahl, Symantec