Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se!cyklop.nada.kth.se!news
From: d88-skl@dront.nada.kth.se (Stellan Klebom)
Newsgroups: comp.sys.amiga
Subject: Re: Lattice/SAS C  5.10 HERE!
Message-ID: <1990Aug24.185241.18275@nada.kth.se>
Date: 24 Aug 90 18:52:41 GMT
References: <14874@shlump.nac.dec.com> <1990Aug24.173432.13867@cs.umn.edu>
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 18

In article <1990Aug24.173432.13867@cs.umn.edu> jdege@donald.UUCP (Jeff Dege) writes:
>
>   Standard C allows for multi-line #defines, and there is no reason to
>expect that a compiler won't support this.  In any case, SAS C 5.10
>allows the user to determine the peprocessor buffer.  LC -z4000 file.
>The default is 3000 bytes for lc1 and 6000 bytes for lc1b.  I expect that
>increasing this will eliminate the problem.

I just wonder why is it so hard for people who managed to create a compiler,
that is actually doing a good job, to make the macro expansion buffer dynamic?
Since there is a option to set it's size then it must be malloc'd anyway!
To me this seems like a fairly easy thing to remove all sofware restrictions
from, and just letting available memory space set the limit.

   Stellan

(This is no flame, just wanted to tell the world about the thing that made me
 upset when I tried to port MIT Scheme to AMIGA using Lattice C 4.0 :)