xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (08/27/90)
sdowdy@carina.unm.edu.UUCP (Stephen Dowdy) writes: [in response to my query whether Lattice C 5.10 still breaks on a long #define, and a reply from barrett(?) that the code was "unstandard C" to use such long #defines:] > 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. Absolutely, and the point I wanted to raise originally; trashing the development environment because the compiler doesn't like the code is an alpha release bug, not something you expect to find in the fifth generation of a commercial compiler. jdege@donald.UUCP (Jeff Dege) responds: > 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. That's the type of thing I was doing; I had a substantial (bigger than a screen) piece of code (it did a heap walk) that was repeated with just variable names changed three places in my software, so I wanted to maintain it in just one place as I was improving its efficiency, and 1) it needed parameterization, so #include wouldn't work; 2) it was being executed on long files on a per bit basis, so I didn't want it to pay the price of a subroutine call per bit, so making it a subroutine call wasn't an option; 3) I don't trust "inline" enough to use it, and the code had to be portable to other systems, so the inline pragma (or whatever) wasn't attractive. Making the code a long #define was the solution of choice, but it got longer as it got better, and eventually it found a bug in the Lattice compiler where a bound wasn't checked before data was copied to a buffer, and "bang", a couple of hours' work lost and the twenty minutes to rebuild my (very rich) Rad: development environment from floppies got paid. Once I learned I couldn't trust the Lattice C compiler to let my in-Rad: development environment survive the compile cycle, I got very conservative (I've got _decades_ of experience with buggy compilers), changed to backing the edited code from Rad: onto floppies before each compile, kept two generations of backups in case the compiler trashed trackdisk.device or something equally delightful on one of its forays into Rad:-destruct mode, and _then_ compiled from Rad: from a copy of the modified code after that. I also replicate the code three places and did parallel maintenance, the headache I was trying to avoid with the long #define, to get the code past Lattice C 5.04's bug. A lot of trouble to pay for someone's compiler design error. Another correspondent wrote that the new compiler 5.10 release allows one to extend (what may be) the (correct) buffer when running the compiler. This is nice, and useful, but it is a band-aid fix, where bullet-proofing the code to survive any input, with error messages as appropriate when compiler design limits are reached, rather than going wild and trashing memory, is the needed crucial repair. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
mab@druwy.ATT.COM (Alan Bland) (08/28/90)
In article <1990Aug27.081810.14126@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >Once I learned I couldn't trust the Lattice C compiler to let my >in-Rad: development environment survive the compile cycle, I got >very conservative (I've got _decades_ of experience with buggy >compilers), changed to backing the edited code from Rad: onto >floppies before each compile, kept two generations of backups in >case the compiler trashed trackdisk.device or something equally >delightful on one of its forays into Rad:-destruct mode, and >_then_ compiled from Rad: from a copy of the modified code after >that. This is not meant to fault your programming skills, but you've been lucky not to have trashed RAD: by a mistake in your own program. I've done it on rare occasions, all you gotta do is get a wild pointer that happens to point into the RAD: area of memory, or at the system vectors that allow it to be recoverable. If you've ever caused the Amiga to go into FIREWORKS_MODE, you can almost bet RAD: went up in smoke with it. When I'm storing critical data like the only copy of a source file in a RAM disk, recoverable or not, I'm worried much more about my own mistakes and by public domain utilities than by a commercial compiler. Sure, you've uncovered a severe bug in Lattice C and there's no excuse for it to crash the machine, but odds are you'll lose more files from a RAM disk while debugging your own code than by compiling it. Keep copies of those files on floppy or HD whether you trust the compiler or not! >Kent, the man from xanth. ><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -- -- Alan Bland -- att!druwy!mab == mab@druwy.ATT.COM -- AT&T Bell Laboratories, Denver CO -- (303)538-3510
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (08/30/90)
mab@druwy.ATT.COM (Alan Bland) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >> [about backing up Rad: onto floppies before compiles] > >This is not meant to fault your programming skills, but you've been lucky >not to have trashed RAD: by a mistake in your own program. I've done it >on rare occasions, all you gotta do is get a wild pointer that happens to >point into the RAD: area of memory, or at the system vectors that allow >it to be recoverable. Oh, but I'm one of those old timers who can write FORTRAN code in any language. You mean C has _pointers_? ;-) Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
walker@unx.sas.com (Doug Walker) (08/31/90)
In article <1990Aug27.081810.14126@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >sdowdy@carina.unm.edu.UUCP (Stephen Dowdy) writes: > >[in response to my query whether Lattice C 5.10 still breaks on a > long #define, and a reply from barrett(?) that the code was > "unstandard C" to use such long #defines:] > >> 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. > >Absolutely, and the point I wanted to raise originally; trashing the >development environment because the compiler doesn't like the code is >an alpha release bug, not something you expect to find in the fifth >generation of a commercial compiler. > >jdege@donald.UUCP (Jeff Dege) responds: > >> 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. > >That's the type of thing I was doing; I had a substantial (bigger than >a screen) piece of code (it did a heap walk) that was repeated with just >variable names changed three places in my software, so I wanted to >maintain it in just one place as I was improving its efficiency, and > > 1) it needed parameterization, so #include wouldn't work; > > 2) it was being executed on long files on a per bit basis, > so I didn't want it to pay the price of a subroutine call > per bit, so making it a subroutine call wasn't an option; > > 3) I don't trust "inline" enough to use it, and the code had > to be portable to other systems, so the inline pragma (or > whatever) wasn't attractive. > >Making the code a long #define was the solution of choice, but >it got longer as it got better, and eventually it found a bug >in the Lattice compiler where a bound wasn't checked before >data was copied to a buffer, and "bang", a couple of hours' >work lost and the twenty minutes to rebuild my (very rich) Rad: >development environment from floppies got paid. > >Once I learned I couldn't trust the Lattice C compiler to let my >in-Rad: development environment survive the compile cycle, I got >very conservative (I've got _decades_ of experience with buggy >compilers), changed to backing the edited code from Rad: onto >floppies before each compile, kept two generations of backups in >case the compiler trashed trackdisk.device or something equally >delightful on one of its forays into Rad:-destruct mode, and >_then_ compiled from Rad: from a copy of the modified code after >that. > >I also replicate the code three places and did parallel >maintenance, the headache I was trying to avoid with the long >#define, to get the code past Lattice C 5.04's bug. > >A lot of trouble to pay for someone's compiler design error. > >Another correspondent wrote that the new compiler 5.10 release >allows one to extend (what may be) the (correct) buffer when >running the compiler. This is nice, and useful, but it is a >band-aid fix, where bullet-proofing the code to survive any >input, with error messages as appropriate when compiler design >limits are reached, rather than going wild and trashing memory, >is the needed crucial repair. > >Kent, the man from xanth. ><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
walker@unx.sas.com (Doug Walker) (08/31/90)
This is getting out of hand. I wish our news feed wasn't so far behind the rest of the net or this might have been resolved before it got so far. Mr. Dolan, I'm sorry you have had a bad experience with the compiler bug you mentioned. However, I don't think it is justified to disparage the professionalism of the entire Lattice C product and its developers based on the presence of a single bug, which, while it SHOULD have been caught, will not be noticed by 99% of all Lattice C customers. The compiler had a bug. We fixed it as soon as possible - in fact, in the 5.05 maintenance release, which is a free upgrade from 5.04. The fix caused an error message to be printed and exited cleanly. In the next large release, 5.10, we put in an option to allow it to compile, by specifying a larger preprocessor buffer. The only criticism you can have on our handling of this matter is the fact that the bug was in there in the first place. I ask your forgiveness in this matter, bearing in mind the difficulty (impossibility?) of producing major products totally bug-free. >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
david@twg.com (David S. Herron) (08/31/90)
In article <6027@drutx.ATT.COM> mab@druwy.ATT.COM (Alan Bland) writes: >This is not meant to fault your programming skills, but you've been lucky >not to have trashed RAD: by a mistake in your own program. That is so very very much beside the point it's not funny. Sure it's a valid point but it simply ain't that hard to check your input or to make dynamically growing buffers. Any program should be able to accept garbage and not barf to the point it crashes the machine. With any procedure you can describe what it is you're willing to accept and have it check that the input actually is what you're willing to accept before running off and doing something crazy. A long time ago I got into the habit of checking inputs with the result that I tend to know very quickly when I've got a bug with information handling & control. Usually this checking is only a couple of pointer or integer comparisons. Nothing fancy.. Want some more justifaction? There's a wonderful book written by Khernigan (Kernighan?) and Plauger titled: Elements of Programming Style. It's written in the style/form of _Elements_of_Writing_Style_ (Strunk and White) but focused on writing software. Each chapter is headed up with horror stories from all elements of computing that boil in some way or another down to bad programming style, be it lack of parameter checking or whatever. Despite the fact that it was written in the 70's the book is still very very valid today. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!