Optimizing out unreferenced variables

Chris Lewis clewis at ferret.ocunix.on.ca
Thu May 9 13:42:08 AEST 1991


In article <13206:May719:03:1491 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <1475 at ecicrl.ocunix.on.ca> clewis at 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 at ferret.ocunix.on.ca
UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request at eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request at eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!



More information about the Comp.unix.programmer mailing list