Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!usc!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga Subject: Long #defines (Re: Lattice/SAS C 5.10 HERE!) Message-ID: <1990Aug27.081810.14126@zorch.SF-Bay.ORG> Date: 27 Aug 90 08:18:10 GMT References: <14874@shlump.nac.dec.com> <1990Aug24.060138.2233@ariel.unm.edu> <1990Aug24.174645.15969@cs.umn.edu> Organization: SF Bay Public-Access Unix Lines: 82 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.