Re: YACC and LEX for Macs

earleh@microsoft.UUCP (Earle HORTON)
10 Jan 90 22:17:05 GMT

          From comp.compilers

Related articles
YACC and LEX for Macs shieber@harvard.harvard.edu (1990-01-08)
Re: YACC and LEX for Macs levin@BBN.COM (Joel B Levin) (1990-01-09)
Re: YACC and LEX for Macs rsfinn@athena.mit.edu (1990-01-09)
Re: YACC and LEX for Macs earleh@microsoft.UUCP (1990-01-10)
| List of all articles for this month |

From: earleh@microsoft.UUCP (Earle HORTON)
Newsgroups: comp.compilers,comp.sys.mac
Date: 10 Jan 90 22:17:05 GMT
References: <1990Jan9.021314.5308@esegue.segue.boston.ma.us> <1990Jan10.021257.11269@esegue.segue.boston.ma.us>
Organization: Windows Group
Followup-To: comp.sys.mac

In article <1990Jan10.021257.11269@esegue.segue.boston.ma.us>
rsfinn@athena.mit.edu (Russell S. Finn) writes:
>Net denizen Earle Horton has apparently ported Bison and Flex to the
>MPW C compiler. Perhaps he will see this and post some of his
>experiences as well.


          Sure. Note: This is me, but the address is a little different.
There are three big problems with porting Flex to a Macintosh
development system, and a few other little ones.


          a) Flex uses lots of global data, chiefly in arrays. Many
development systems for the Macintosh do not allow more than 32k of
global data. The approach I chose to use in porting Flex 2.x was to use
Aztec C 3.6c with the "large data" model. For THINK C, you may want to
convert a bunch of arrays to pointers, then allocate the space for these
pointers from the heap.


          b) The Macintosh character set uses all eight bits of a character.
Flex uses the high-order bit as a flag, and in addition uses raw chars
as array subscripts. Combine this with signed chars, and you have a
recipe for program death. Chars have to be masked to eight bits in
numerous places within Flex, and the code which uses the high bit as a
flag has to be rewritten. I strongly recommend that you obtain the code
from my port of Flex, rather than attempting this task yourself.


          c) The line demarcation character used in Macintosh 'TEXT' files is
conventionally the carriage return character, with decimal value 13.
Flex uses a hard-coded '\n' in numerous places to denote newline, and
'\n' is equal to 10 in most non-weird C implementations. To make Flex
work with Macintosh 'TEXT' files, either filter the input and output so
that Flex sees an end of line as a '\n', or change Flex to use '\r'
instead of '\n' everywhere.


          There is an ftp archive at ohio-state where you can find a copy of
Berkeley Yacc which is free to use and not subject to the GNU Copyleft.
I ported this to Aztec C 3.6c, and sent a copy of the sources to sumex
while I was still doing Macintosh development. Porting to THINK C
should be relatively straightforward.


Earle R. Horton





Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.