Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!jarthur!mti!adrian
From: adrian@mti.mti.com (Adrian McCarthy)
Newsgroups: comp.lang.c
Subject: Re: When should variables within blocks be allocated?
Message-ID: <886@mti.mti.com>
Date: 22 Jan 90 17:43:57 GMT
References: <253@usblues.UUCP> <26449@stealth.acf.nyu.edu> <15699@haddock.ima.isc.com>
Reply-To: adrian@mti.UUCP (Adrian McCarthy)
Distribution: usa
Organization: Micro Technology, Anaheim, CA
Lines: 27

In article <15699@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer)
writes:

>[compilers are] free to optimize things away.  In
>particular, unused variables need not be allocated.  Such compilers exist.

So the relatively common practice of trying to get an identification string
into the object and executable files by declaring an otherwise unused
character string may be pointless.  For example, many programmers put a line
like:

  static char *RCSid = "$Header$";

into their code.  When they check it out from their configuration management
system (RCS in this example), $Header$ gets expanded to an identification
string.  Later, they expect a strings-type command to spit out the expansion
of the $Header$.  But if RCSid is never used anywhere else in the program,
some compilers might optimize it away.

A better solution would be to provide a switch/option/qualifier to the
program which simply outputs the string.  That would guarrantee RCSid is not
optimized out and it allows folks on systems without a strings-type command
to also get this information.

>Karl W. Z. Heuer (karl@haddock.isc.com or ima!haddock!karl), The Walking Lint

Aid.