Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!ncar!mephisto!mcnc!rti!mozart!walker From: walker@unx.sas.com (Doug Walker) Newsgroups: comp.sys.amiga Subject: Re: Long #defines (Re: Lattice/SAS C 5.10 HERE!) Message-ID: <1990Aug30.183543.12351@unx.sas.com> Date: 30 Aug 90 18:35:43 GMT References: <1990Aug24.060138.2233@ariel.unm.edu> <1990Aug24.174645.15969@cs.umn.edu> <1990Aug27.081810.14126@zorch.SF-Bay.ORG> Organization: SAS Institute Inc. Lines: 83 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. >