Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Problems porting bison and flex to THINK C 4.0
Message-ID: <15607@dartvax.Dartmouth.EDU>
Date: 16 Sep 89 00:05:26 GMT
References: <1687@petsd.UUCP>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 66

In article <1687@petsd.UUCP> jac@petsd.UUCP (Jim Clausing) writes:
>I got the source for flex and bison off of sumex recently and last night
>decided to try porting them since they are both MPW C (by the way, if anyone
>else has already ported them and would like to save me the trouble, I would
>be greatly obliged, assuming that that is not the case ...).  I've run into
>some slight difficulties and maybe a more major one.
>
>Small problem #1: I get link errors with undefined bzero and mktemp.  I know 
>that there is a PD C version of bzero floating around and I will try to find 
>that, what about mktemp?

The latest version of Flex on Sumex used Aztec C.  It has not been
ported to MPW C yet.  Bzero() is trivial to implement.

bzero(array, size)
	char           *array;
	long            size;
{
	register long   i;
	for (i = size; i-- > 0;) {
		array[i] = 0;
	}
}

Check the size parameter to see if you want a long or an int there.

Mktemp() generates a unique file name from a template.  The Aztec
library contains one.  For a single-user system, you can usually
assume that the template passed to mktemp() is sufficiently obscure
that it will not conflict with any permanent files, e.g.
"/tmp/flexXXXXXX" and you can write a function that just returns the
address passed to it.

>
>Small problem #2: alloca.  There are two assembler versions of this included,
>but I don't have an assembler at present.  Having never used the TC inline
>assembler, how difficult would it be to take one of these assembly sources
>and produce something that TC could handle?  Should I not bother?  Is there
>a C version that (while perhaps slower) is useable.

Alloca() is dangerous.  You need to know whether your compiler stores
temporaries on the stack, and if so how many of them.  The alloca()
supplied with these programs copies the largest anticipated register
save area before dropping the stack pointer, so that when the parent
function returns it can restore its caller's registers.  If you are
using MC68881 code, the size of the save area needed will be much
larger than provided for.  If this is starting to sound a bit obscure,
then you might need the C version.

Assuming you have figured out the size of the largest possible
temporary save area on the stack as used by TC, I should think porting
the assembler code to TC inline "asm" should be real easy.

>
>Bigger problem (and petty gripe):  (Before I even start, let me say that I
>really like TC and I think the Symantec folks have done a great job, I've
>been drooling all over the class library chapters of the manual, but haven't
>had much time to play with it yet).  The ever-present and truly obnoxious
>data segment too big error (32K limit on data segment size).  I don't want
>to make wholesale changes to the code, is there an easy workaround for this?
>What did MPW do, since this code apparently compiles there without problem?

This is real easy.  I compiled it with the large data option.  Not so
easy for you, eh?

Earle R. Horton