Re: Usability advice to compiler/interpreter authors

claird@Starbase.NeoSoft.COM (Cameron Laird) writes:


      Compiler/interpreter authors, please give us users analysis-time
      access to version, platform, and invocation data (especially the
      first of these).


      [A counter theory decries bushy ifdefs as making reliable code much harder
      to write. I have sympathy for both camps. -John]


These are not incompatible camps. One can easily avoid writing "bushy
ifdefs" while taking advantage of access to version info provided
by a friendly compiler. The result can be even more reliable code.


For example, gcc-2.7.0 adds warnings about unused parameters, as in
"void foo (int i) { }". It also allows a new way to specify that it
is okay for a parameter to be unused, to avoid the new warning.


In my software, I like to enable all (reasonable) warnings, so for
its new version, I was getting all sorts of warnings about unused
parameter from gcc-2.7.0. All, or almost all, of these were
verified to be expected (I can't remember whether any bugs were
uncovered, as turning on warnings in the past definitely has done for
me), so to disable them I changed function definitions to, e.g.,
"void foo (int i UNUSED) { }".


Then, it was easy in a central file to "#define UNUSED" to either the
new construct saying "__attribute__ ((unused))" or, if my software,
which people might still want to compile with pre-2.7.0 versions of
gcc, nothing.


Fortunately, gcc tells its preprocessor to pre-defined __GNUC__ as
the major version number and __GNUC_MINOR__ as the minor version number,
so choosing which definition of UNUSED to set up was quite easy.


Had gcc not provided this information, and had I been in no position
to spend a bunch of time to "engineer" my way around this, I might
have been tempted to disable the new warning. If this sort of thing
became a trend, my software might be built with some warnings disabled,
warnings that could otherwise have shown bugs lurking in the code!
But gcc made it easy to handle the multiple-compiler problem.


Even better, the way gcc does this allows other languages that use
preprocessors at all compatible with cpp to provide this feature
(when they're built as part of gcc). So my software, which happens
to be g77 (a Fortran compiler built with the gcc back end), pretty
much automatically offers this exact same feature to people who
use it with the preprocessor!


So based on my practical experience as a long-time compiler user and
medium-time writer, I agree 100% with the plea that compilers provide
this kind of information whenever possible.


That being said, given the limitations of the C preprocessor, it's
hard to imagine how to usefully encode platform and invocation data.
Most of this info is inherently non-numeric. gcc does define
__OPTIMIZE__ depending on whether on optimization level greater than
zero (0, meaning none) is requested, and it could probably define
it to the (nonzero) optimization level selected if that seemed
useful. (It could also define a __DEBUG__ macro as the debugging
level, e.g. `-g' would yield 2, but the gcc people are pretty emphatic
that `-g' should never change the generated code itself so maybe they
consciously decided to never do this themselves.)


To make platform/invocation data useful in cpp, it'd probably have
to be numericized, and that'd require as widespread coordination of
such information as is done for a compilers' version numbers -- and
even for that info, such coordination can be pretty shaky at times
(e.g. forgetting to update the version numbers everywhere before
release, or having bugs in the tools used to do this automatically).


Project GNU made one very good decision making this version info
easy to encode -- its version info is 3 decimal integers. Things
would be more of a hassle if they had version numbers like "1A(632)"
(wasn't this the old TOPS-10 convention? ;-).


Of course, anyone shipping a modified version of gcc should be
"friendly" by including an appropriate #define (-D option to cpp)
that gives "subversion" info (an appropriate name, eh?) so code
needing to distinguish between gcc-2.6.3 and, say, gcc-i2.6.3
(which I gather is a version hacked to do better Pentium
optimizations, but I know nothing else about it) can do so by
testing an appropriate macro.
--


James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.