Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!ux1.cso.uiuc.edu!midway!arthur!francis
From: francis@arthur.uchicago.edu (Francis Stracke)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Mac C Compiler?
Message-ID: <1990Sep26.225549.17792@midway.uchicago.edu>
Date: 26 Sep 90 22:55:49 GMT
References: <1990Sep24.184845.12502@ux1.cso.uiuc.edu>
Sender: news@midway.uchicago.edu (News Administrator)
Organization: Mathematics Department, University of Chicago
Lines: 23

In article <1990Sep24.184845.12502@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
>
[...]
>I tried compiling this on the Mac with a borrowed copy of Lightspeed C
>and it failed. These are large programs - a couple of megabytes
>of global data and several very large subroutines (that compile to
>somewhere between 50 and 125 kbytes of code on varying computers).
>Lightspeed C apparently thinks it is too big.

Damn straight, it's too big! Macs use a variety of segmenting that puts each
segment of your program into its own code resource (if you don't know, don't
worry).  No resource can be bigger than 32K (theoretically--I've seen some
sound resources get around it somehow--but it's probably tricky and risky
enough that no compiler would do it, especially with work-arounds available--
see below).  No subroutine can be spread across more than one segment
(reasonable, no?).  Therefore, no subroutines over 32K.

What you need to do is break up those subroutines, so that their pieces come out
less than 32K each, then put pieces into separate segments.  What are
you doing with routines that big, anyway? What's the point of structure?

BTW: the reason resources aren't supposed to be over 32K is that their sizes are
expressed as integers (maxint=32767).