tron1@tronsbox.xei.com (HIM) (08/22/90)
Ok, I just receive my SAS/C (Lattice C) 5.10 upgrade in the
mail and figured I would post my initial impressions.
I LIKE IT. I have been a customer of SAS for DOS products for
a while as a consultant (the make great courseware) and always like
the company. Anyone who was worried about the quality or dedication
of this company to this product can breathe easy.
The upgrade comes with 6 disks ( a whole new installation set ,
not patches BTW ) and some new pages to the manual.
Here are the high points :
1) The LSE integrated editor environment now supports AREXX.
2) The LSE editor is now compatible with 8/16 color
workbenches.
3) The linker (BLINK) is faster in 5.10 by up to 200%
4) WORKBENCH COMPATIBLE :
This will help those new to the C world on the Amiga
all program development can be done under icon and
point/click control. There is a VERY nice program
to set compiler options that can help EVERYONE get
better use out of the compiler.
5) LPROF - the profiler, now supports multiple code hunks.
6) The assembler now supports EQUR.
7) _aligned - this will allow you to say ..
struct FileInfoBlock _aligned foo;
that will force foo to be longword aligned.
8) Prototype Generation - LC and LC1B's -pr option generates
prototypes and now supports TYPEDEF'ed names.
9) Option added to expand the limits in the pre-processor.
10) ALTERNATE startup code :
c.o - standard startup code.
cback.o - Detaches process from CLI and runs it in
the background ala runback.
cres.o - Makes it possible to RESIDENT the program.
This startup code makes a copy of the data
section each time it is invoked, so each
invocation will get a differnt data section.
Thus, all programs linked with cres.o can be
placed on the resident list as PURE.
You must have less than 64k of external
data to use cres.o
catch.o,
catchnr.o - Produces a snapshot on software
exceptions. catch.o will put up a
requester and ask if you want a snapshot
file written and catchnr.o just writes it.
The TB command can read snapshot files
and tell you what was happening when it went down.
(shades of core dump ?? )
catchres.o,
catchresnr.o - a combination of catch.o and res.o .
11) Auto near to far - LC1 will move near data to far
if you attempt to decalare to much near
data.
12) no sizeof warning -
sizeof( *foo )
is valid now even if foo is not initialized.
13) offset macros - Support for all varieties of offset
macro that we know of, including those in
GNU and XWindos code.
14) C++ comments - LC1 now supports C++ style comments ..
j = 0; // Initialize j (this is a comment)
15) New warnings added.
16) Performance inproved in generated code.
17) #pragma limit - raised to 14. ALL Amiga library calls can
now be made with all parameters in registers.
18) Minimum stack size - 5.10 allows a stack variable to be
set at compile time.
When the code is run, it will set the stack to
this size on its own.
19) Libraries -
opendir, readdir, seekdir, telldir
rewindir, closedir, stat and isatty
Now equate to the UN*X counterparts.
20) AMIGADOS 2.0 SUPPORT.
ALL programs and utilities in this evironment will
function under 2.0 with the new imagery, and 2.0
include and header files are part of the environment.
ALL IN ALL ... not bad for 40$ !!!!
========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]========
= "And in the darkened offices, the terminals shine like stars." =
============= Ken Jamieson: uunet!tronsbox.xei.com!tron1 ==================
= NONE of the opinions represented here are endorsed by either =
= Xanadu Enterpises or its clients, AT&T Bell Labs or others. =
==== The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ==== xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (08/23/90)
So tell me, does it still do a no-warning, no guru, stone cold system crash, trashing Rad:, if you try to do/use a 30 line #define? That was one of 5.04's more adorable habits. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
nfs1675@dsacg3.dsac.dla.mil ( Michael S Figg) (08/23/90)
In article <26d1f3d3-2894comp.sys.amiga@tronsbox.xei.com>, tron1@tronsbox.xei.com (HIM) writes: > > 1) The LSE integrated editor environment now supports AREXX. > > 2) The LSE editor is now compatible with 8/16 color > workbenches. These modifications sound great, but does anybody really use LSE? No smiley, that was a serious question. How does it compare with other editors? ---Mike, -- A man said to the Universe "Sir, I exist!" | Michael Figg DSAC-FSD "However," replied the Universe, | DLA Systems Automation Center "The fact has not created in me a | Columbus, Ohio sense of obligation."- Stephen Crane | mfigg@dsac.dla.mil CIS: 73777,360
gerry@dialogic.UUCP (Gerry Lachac) (08/23/90)
Does anyone know if Lattice/SAS is doing a trade-in-your-MANX-for-ours
deal like they did a while ago? The features in this release make it
very tempting to make the switch...
--
uunet!dialogic!gerry | "Even a dead plant turns | Dialogic Corporation
OR | over a new leaf | 300 Littleton Rd
gerry@dialogic.UUCP | when the wind blows." | Parsippany, NJ 07054
| | (201)334-8450barrett@meridn.enet.dec.com (Keith Barrett) (08/24/90)
In article <1990Aug23.052447.24545@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes... >So tell me, does it still do a no-warning, no guru, stone cold system >crash, trashing Rad:, if you try to do/use a 30 line #define? Standard C coding practice recommends that a define should fit in 1 line of 80 characters; I think you got what you deserved. You're not the type to sue a ladder company because the instructions did not state "don't place the ladder in mud" and you did and fell, are you? :-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Keith G. Barrett - Software Specialist Internet: barrett@meridn.enet.dec.com Digital Equipment Corp. "DEC has it now" UUCP: decwrl!meridn.enet!barrett // "Wait'll they get a load of me" - Joker \X/ "The Amiga is really a picoVAX" "You won't get it!" - the Prisoner ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tron1@tronsbox.xei.com (HIM) (08/24/90)
Lines: 40 >Resp: 2 of 3 About: Re: Lattice/SAS C 5.10 HERE! ><> [Kent Paul Dolan] (*Masked*@zorch.SF-Bay.ORG) > >So tell me, does it still do a no-warning, no guru, stone cold system >crash, trashing Rad:, if you try to do/use a 30 line #define? Well, being as I have never seen anyone do a 30 line define I wouldn't know. Was this a problem with the editor (I doubt that though) or the compiler ?? Send me some code and I wil gladly test it and let you know. >Resp: 1 of 3 About: Re: Lattice/SAS C 5.10 HERE! ><> [ Michael S Figg] (*Masked*@dsacg3.dsac.dla.mil) > >These modifications sound great, but does anybody really use LSE? No smiley, >that was a serious question. How does it compare with other editors? I use it all the time. Once I got over having the keys in different places than the vi editor I use at Bell Labs it is fine. I like it a lot. As a EDITOR is is in the middle of the pack, it is "C" aware so can help you out that way , but it is so convenient to have it tied so close to the compiler. The new versions AREXX port take care of all the problems I had , any command I need I can add. I am NOT one of those "I need my editor to do everything including change the diapers on my baby" types... I work across 3 architectures (Amiga , DOS, and UNIX) of 5 differnt machine types and so do NOT rely on editor functions that much myself. ========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]======== = "And in the darkened offices, the terminals shine like stars." = ============= Ken Jamieson: uunet!tronsbox.xei.com!tron1 ================== = NONE of the opinions represented here are endorsed by either = = Xanadu Enterpises or its clients, AT&T Bell Labs or others. = ==== The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ====
sdowdy@carina.unm.edu (Stephen Dowdy) (08/24/90)
In article <14874@shlump.nac.dec.com> barrett@meridn.enet.dec.com (Keith Barrett) writes: }In article <1990Aug23.052447.24545@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes... }>So tell me, does it still do a no-warning, no guru, stone cold system }>crash, trashing Rad:, if you try to do/use a 30 line #define? } }Standard C coding practice recommends that a define should fit in 1 line }of 80 characters; I think you got what you deserved. You're not the type }to sue a ladder company because the instructions did not state "don't }place the ladder in mud" and you did and fell, are you? :-) } }~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ }Keith G. Barrett - Software Specialist Internet: barrett@meridn.enet.dec.com Woah!!! I don't recall anywhere where it says "#define lines should adhere to ancient FORTRAN coding practices". Admittedly, I'd never write a 30 line #define, but it is not too much to expect software not able to deal with such excess to at least abort with an error, or truncation of the directive. I think a better analogy than the one you give would be: ...sue an automobile manufacturer because you went 70mph and the car exploded because everyone *KNOWS* it is standard driving practice to do only 65... In addition (since you are from DEC), i suppose that you would have no problem if i had a 30 line #define and VAXC crashed my vax, eh? (I'm sure the rest of the users on my system would be rather irked) I realize that software has bugs that may not have been exercised in testing which is understandable, but to say that it is acceptable for software to explode on strange input is ludicrous. --stephen dowdy -- $! stephen dowdy (AOSED@acvax.inre.asu.edu) $! BITNET: sdowdy@unmb $! Internet: sdowdy@law.UNM.EDU $! Team SPAM in '87! SPAAAAAAAAAAAAAAAAAAAAMMMMMMM!
ken@cbmvax.commodore.com (Ken Farinsky - CATS) (08/24/90)
In article <14874@shlump.nac.dec.com> barrett@meridn.enet.dec.com (Keith Barrett) writes: >Standard C coding practice recommends that a define should fit in 1 line >of 80 characters... Another message guaranteed to get a million responses! >Keith G. Barrett - Software Specialist Internet: barrett@meridn.enet.dec.com ^^^^^^^^^^^^^^^^^^^ ??? -- -- Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines uucp: ...{uunet,rutgers}!cbmvax!ken bix: kfarinsky
jdege@ (Jeff Dege) (08/25/90)
In article <14874@shlump.nac.dec.com> barrett@meridn.enet.dec.com (Keith Barrett) writes: >Standard C coding practice recommends that a define should fit in 1 line >of 80 characters; I think you got what you deserved. You're not the type >to sue a ladder company because the instructions did not state "don't >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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. ------- .signature - ???
jdege@ (Jeff Dege) (08/25/90)
In article <1990Aug24.060138.2233@ariel.unm.edu> sdowdy@carina.unm.edu.UUCP (Stephen Dowdy) writes: >In article <14874@shlump.nac.dec.com> barrett@meridn.enet.dec.com > >Woah!!! >I don't recall anywhere where it says "#define lines should adhere to >ancient FORTRAN coding practices". Admittedly, I'd never write a 30 line >#define, but it is not too much to expect software not able to deal with >such excess to at least abort with an error, or truncation of the directive. > Howabout: #define DPRINT(type, var) \ { \ char buf[80]; \ sprintf(buf, "%s = %" type; #var, var); \ msg_disp(buf); \ } /* usage is DPRINT(d,intvar);, and msg_disp() displays a string in a window in a system-friendly way. */ Extending this sort of thing soon leads to fairly long #defines. ----------------------------------------- ......................................
d88-skl@dront.nada.kth.se (Stellan Klebom) (08/25/90)
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 :)
jeh@sisd.kodak.com (Ed Hanway) (08/25/90)
In article <14874@shlump.nac.dec.com> barrett@meridn.enet.dec.com (Keith Barrett) writes: >In article <1990Aug23.052447.24545@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes... >>So tell me, does it still do a no-warning, no guru, stone cold system >>crash, trashing Rad:, if you try to do/use a 30 line #define? > >Standard C coding practice recommends that a define should fit in 1 line >of 80 characters; I think you got what you deserved. Overflowing a compiler limit might deserve an error message, but certainly not a system crash. Start doing stuff like #define putrgb(x) do { putchar((x).r); putchar((x).g); putchar((x).b)} while(0) and you can run up against preprocessor limits in a hurry. On the sun I'm using to enter this message, "putrgb(a_big_struct_name->member)" expands to about 1350 characters. Kudos to Lattice, er, SAS for finally allowing the limit to be expanded. Ed
chris@genly.UUCP (Chris Hind Genly) (08/25/90)
>In article <1990Aug23.052447.24545@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes... >So tell me, does it still do a no-warning, no guru, stone cold system >crash, trashing Rad:, if you try to do/use a 30 line #define? >In article <14874@shlump.nac.dec.com> barrett@meridn.enet.dec.com (Keith Barrett) writes: >Standard C coding practice recommends that a define should fit in 1 line >of 80 characters; I think you got what you deserved. You're not the type >to sue a ladder company because the instructions did not state "don't >place the ladder in mud" and you did and fell, are you? :-) I see the smiley, but I assume it only applies to the preceding sentence, not the whole paragraph. First I have to object to "you got what you deserved." A compiler should not crash when it runs into a limitation. This is clearly a bug and should be fixed. Second, Multi-line macros are legitimate in C. I use them all the time. As an example of a useful multi-line macro see the code below. Macros are wonderful because they let you "escape from the language". C does not directly support iteration abstraction. With macros I can write my own. C does not support inlining. With macros I can do my own inlining. In each case the macros are usually longer than one line. ==================================================================== /* * File iterators * * 8/25/90 Chris Hind Genly chris@genly.uucp * * No rights reserved. * */ #ifndef file_h #define file_h #ifndef stdin #include <stdio.h> #endif #include <proto/dos.h> #include <libraries/dos.h> /* * Iterate through all files in a directory. * * The user declares dir as either a character pointer or character array. * It should be set to a directory path string. * The macro declares fi, and path. Fi is the Amiga file info block. * Path is a char array containing the path to a file in the dir. * Fi and path may be referenced in the body of the for. * Break and continue are permitted inside this iterator. * * Example: * * FOR_ALL_FILES("c:", fi, path) { * printf("%s: %d\n", path, fi->fib_Size); * } END_FOR_ALL_FILES; */ #define FOR_ALL_FILES(dir, fi, path) \ { \ BPTR lock; \ static struct FileInfoBlock fis, *fi=&fis; \ int ok; \ char path[200], *sep; \ \ switch(dir[strlen(dir)-1]) { \ case '/': case ':': sep = ""; break; \ default: sep = "/"; break; \ } \ \ lock = Lock(dir, ACCESS_READ); \ if (lock == 0) { \ fprintf(stderr, "snews: unable to lock %s\n", dir); \ exit(1); \ } \ \ ok = Examine(lock, fi); \ while(ok = ExNext(lock, fi)) { \ strcpy(path, dir); \ strcat(path, sep); \ strcat(path, fi->fib_FileName); #define END_FOR_ALL_FILES \ } \ \ UnLock(lock); \ } /* * Iterate through all directories of a directory. * * Same as above, except the body is only executed for directories. */ #define FOR_ALL_DIRS(dir, fi, path) \ FOR_ALL_FILES(dir, fi, path) \ if (fi->fib_DirEntryType <= 0) continue; #define END_FOR_ALL_DIRS \ END_FOR_ALL_FILES #endif ==================================================================== * * * \|/ * _______ --O-- ____/ KC1VP \____ * /|\ * _____________/ (203) 389-8680 \_______________ ______/ 95 Fountain Terr., New Haven, CT, USA, 06515 \_______ / Chris Hind Genly chris@genly.uucp uunet!hsi!genly!chris \ ----------------------------------------------------------------
barrett@meridn.enet.dec.com (Keith Barrett) (08/25/90)
OK OK OK, I give. I quoted the statement right from the Waite Group's C Primer Plus book, page 331, suggested that since not all compilers allow long statements, that it is best to limit it to 1 line. It also wasn't the first time I heard it. It would have made more sense to stick to the K&R book. I apologize. Can I keep my title now? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Keith G. Barrett - Software Specialist Internet: barrett@meridn.enet.dec.com Digital Equipment Corp. "DEC has it now" UUCP: decwrl!meridn.enet!barrett // "Wait'll they get a load of me" - Joker \X/ "The Amiga is really a picoVAX" "You won't get it!" - the Prisoner ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (08/27/90)
barrett@meridn.enet.dec.com (Keith Barrett) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes... >>So tell me, does it still do a no-warning, no guru, stone cold system >>crash, trashing Rad:, if you try to do/use a 30 line #define? >Standard C coding practice recommends that a define should fit in 1 line >of 80 characters; I think you got what you deserved. You're not the type >to sue a ladder company because the instructions did not state "don't >place the ladder in mud" and you did and fell, are you? :-) Heavens, if multiple line #defines are "broken", then most of Unix code is garbage; the backslash line continuation is there for a purpose. More important, is not whether my code is pretty or not, but whether Lattice C is bulletproof or not. In general, compilers process 100 buggy files for every one bug free file, so dying on buggy code is not acceptable behavior. A compiler should be able to eat any stream of bytes without dying; dropping dead based on user (code) input is a symptom of failing to check whether a process is safe before executing it, rather silly when you are expecting code errors in the imput, and are supposed to handle it without a hiccup. It is a standard test for a compiler to feed it random input to make sure it survives intact. Probably more important is to feed it a file that exceeds every known limitation of the compiler and assure that it handles each gracefully, mine among them. Trashing the system on any input is the compiler writer's error, and blaming it on the user is looking away from the problem. The proper analogy isn't with having a ladder fall over in mud, but with having it collapse when a 200kg housepainter uses it because the ladder designer couldn't imagine someone that size elevating himself off the ground, and built the ladder too wimpy to carry the load. Better yet, compare with Fredericks of Hollywood, who sell garb to make ladies feel seductive, but ignore the ladies most in need of their product, the ones wearing the 3X and 4X sizes, thus losing over half the market in this obese society. We rotten programmers are a much bigger market than the hypercompetent, and Lattice should target their compiler for our needs, not theirs. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (08/27/90)
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >We rotten programmers are a much bigger market than the hypercompetent, >and Lattice should target their compiler for our needs, not theirs. Following up my own posting. Gag! What I should have said: We rotten, daring, or compiler abusing programmers are a much bigger market than the hypercompetent, rule following, or very conservative programmers who would never think of stress testing a compiler, and Lattice should target and implement their compilers for our needs, not theirs. Since the distinction as said originally was unfair to (some of) those whose programs break buggy compilers, and unfairly praised (some of) those whose programs don't. ;-) Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
walker@unx.sas.com (Doug Walker) (08/28/90)
In article <1990Aug23.052447.24545@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >So tell me, does it still do a no-warning, no guru, stone cold system >crash, trashing Rad:, if you try to do/use a 30 line #define? > >That was one of 5.04's more adorable habits. > Which was fixed in 5.05, although it never caused a system crash on my Amiga, just a snapshot. 5.05 refused to compile the file, but didn't crash; in 5.10 you can set the preprocessor buffer size high enough to handle any macro, as long as you have the memory for it. BTW, try using lc1b instead of lc1 to compile your 30-line macro; lc1b in 5.04 had a preprocessor buffer of 8k rather than 4k in lc1, and it will very likely handle your macro. ***** =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 = *|. o.| || | o |// For all you do, this bug's for you! ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker
walker@unx.sas.com (Doug Walker) (08/28/90)
In article <1310@dialogic.UUCP> gerry@dialogic.UUCP (Gerry Lachac) writes: > >Does anyone know if Lattice/SAS is doing a trade-in-your-MANX-for-ours >deal like they did a while ago? The features in this release make it >very tempting to make the switch... > Yes, that offer is still good. Call the Institute for info: (919)677-8000 and ask for "book sales - Amiga compiler". ***** =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 = *|. o.| || | o |// For all you do, this bug's for you! ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker
walker@unx.sas.com (Doug Walker) (08/30/90)
In article <1990Aug24.185241.18275@nada.kth.se> d88-skl@dront.nada.kth.se (Stellan Klebom) writes: >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. In 5.10 it is malloc'd, but only once (at the beginning). If we provide for reallocating it, we would have to locate every place that has a pointer into the buffer and change the pointers to point into the new buffer. This would be possible, but we judged it too risky for the 5.10 release and delayed it until 6.0. ***** =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 = *|. o.| || | o |// For all you do, this bug's for you! ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker
walker@unx.sas.com (Doug Walker) (08/31/90)
In article <1990Aug26.225427.4594@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >Heavens, if multiple line #defines are "broken", then most of Unix code >is garbage; the backslash line continuation is there for a purpose. The previous poster's comments were definately out of order; there is absolutely nothing wrong with multiple-line #defines. The 5.04 lc1 did have a limitation of (I believe) 3000 bytes in a single preprocessor macro definition. You encountered a bug when you exceeded a compiler limit. This should have produced an error message and terminated compilation. It instead gurued your machine. The bug was fixed in 5.05 in that it no longer gurued the machine. It was fixed in 5.10 such that you can, by specifying a preprocessor buffer size large enough, successfully compile the code. The 5.04 lc1b also has a larger buffer, which might allow you to compile with 5.04. >More important, is not whether my code is pretty or not, but whether >Lattice C is bulletproof or not. Any large programming project has bugs. SAS Institute is committed to fixing them, and we have done so in this case. >each gracefully, mine among them. Trashing the system on any input is the >compiler writer's error, and blaming it on the user is looking away from >the problem. I would like to point out that no one from SAS Institute blamed this on your code. I agree that this was a compiler bug. Compiler bugs that guru the system are quite rare and we give them the highest possible priority. >We rotten programmers are a much bigger market than the hypercompetent, >and Lattice should target their compiler for our needs, not theirs. This in no way reflects on SAS's target market. A bug can creep in anywhere, and in this case did. I suggest that if you choose not to upgrade to the 5.10 release that you at least upgrade to the FREE 5.05 patch release to get rid of the guru. You can also try compiling with lc1b instead of lc1, which has a bigger preprocessor buffer and might compile the file in 5.04. >Kent, the man from xanth. ><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> ***** =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 = *|. o.| || | o |// For all you do, this bug's for you! ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker