Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!mauxci!eci386!ecicrl!clewis From: clewis@ferret.ocunix.on.ca (Chris Lewis) Newsgroups: comp.unix.programmer Subject: Re: Optimizing out unreferenced variables Message-ID: <1477@ecicrl.ocunix.on.ca> Date: 9 May 91 03:42:08 GMT References: <608@elroy> <1475@ecicrl.ocunix.on.ca> <13206:May719:03:1491@kramden.acf.nyu.edu> Organization: Elegant Communications Inc., Ottawa, Canada Lines: 49 In article <13206:May719:03:1491@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1475@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >> I've not tried this myself, but I would presume that if the compiler >> is ANSI compliant, you can probably declare such variables "volatile" >> and the compiler will not optimize them out. Volatile does work in >> similar situations with the RS/6000 compiler. >It's a whole bunch more portable and useful to give the user some >options to print out those strings. End of story. What exactly do you mean by this? what(1)? (how do you get the strings to stay in the binary without volatile in such compilers?) A -V option? (ain't adequate - software frequently has more than one version number - the version of each submodule is also important in bug tracking in big systems. Or for identifying version numbers of the library routines you linked with) It's a little more general problem than just SCCS or RCS idents. Such as operations on hardware devices being reordered or being optimized out in device drivers. But you already knew that. SVR3's "#ident" stuff is nice, but unfortunately rather unportable (the string isn't in .text or .data - and isn't part of the executable image). SCO's damn Xenix C compiler kacks on cpp directives it doesn't like even if ifdef'd out: #ifdef NEVER #ident .... #endif Grrrrr..... This is more portable than "#ident": #ifdef __STDC__ #define VOLATILE volatile #else #define VOLATILE #endif #ifndef lint VOLATILE static char SCCSID[] = "@(#)...."; #endif ("VOLATILE static" does seem like an oxymoron doesn't it? ;-) [No, the semantics are not in conflict]) -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!