rcbc@honir.cs.cornell.edu (Robert Cooper) (09/12/89)
GNU CC compatibility
====================
The next release of ISIS will compile with gcc, the GNU C compiler.
There are several advantages to using gcc:
* It is an ANSI standard C compiler, and does proper typechecking of function
calls. We have added "function prototypes" for all the user-callable ISIS
functions to the header files. E.g. isis_entry is now declared in "isis.h" as
int isis_entry (int entry, void (*routine)(message *msg), char *rname);
If this means nothing to you, go buy the second edition of Kernighan and
Ritchie.
* gcc allows debugging of optimized code (i.e. gcc -g -O is legal).
* it has a set of optional, good quality warning messages.
The ISIS sources still compile successfully with the Sun C compiler, (and
the other "old" C compilers that we have access to) so you don't have to
switch over to using gcc if you don't want to. You should be able to call
gcc compiled code from Sun C compiled code and vice versa. We expect that
ISIS will also compile successfully with other ANSI C compilers, but we
have no way of verifying this ourselves. If you experience difficulties,
or fix a bug send mail to isis-bugs@cs.cornell.edu.
C++ compatibility
=================
The ISIS libraries may now be used from C++ client programs. We have done
so successfully from AT&T C++ version 1.2. We expect it should work also
from g++, the GNU C++ compiler, and AT&T version 2.0, perhaps with minor
changes. Until C++ settles into more of a standard we probably won't invest
much effort into maintaining C++ compatibility. There are no immediate
plans to make the ISIS libraries more object-oriented by using classes and
inheritance.
Release Info
============
The next release will be called ISIS V1.3, and will be made in the next
week or so. Besides gcc compatibility, it will include a number of
bugfixes, including those bugs reported on this newsgroup recently.
(Some of you working more closely with us have picked up pre-release 1.3.
That is not the real release).
By default the makefiles will use the standard C compiler in your
environment. You will have to edit the options at the top of
one makefile to use gcc. Details will appear in the release.
Experiences with gcc
====================
I spent quite a while getting ISIS to compile with gcc, and yet
still compile with the old Sun C compiler. Here are my experiences.
The first task was to generate the function prototypes. I was able
to semi-automate this using the "whatis" command of dbx to obtain
an approximation to a function header with implicit types filled in.
Running dbx from a script of external routine names generated from "nm",
and then massaging the result with Emacs macros reduced the amount of
manual editting by over 50%.
The next stage was getting a clean compile from gcc. Gcc provides quite
high quality error and warning messages which identified a small number of
inconsistent return values, and unused variables in ISIS. Mostly the
warnings identified which functions should return "void" rather than "int".
One of the most useful gcc features here is that when a function definition
mismatches its previous declaration, gcc identifies both source locations.
This obviates the need to "grep" for the original definition. All of ISIS
except the "protos" program now compiles with "gcc -W" which enables most
warning messages. The demo programs pass "gcc -Wall".
Getting ISIS to still compile successfully under Sun C required a number
of compromises. The header files contain two sets of function declarations
conditionally compiled depending on the value of the __STDC__ macro which
is, by convention, only defined by ANSI C compilers. However actual
definition of the function along with its body is written in old C. Of
course this mixing of old and new style declarations is not guaranteed to
work in any ANSI standard C compiler, but gcc does a good job here.
More troublesome was that the ANSI C variable argument syntax could not be
used, even in the header files. For instance declaring msg_get as
int msg_get(char *format, ...)
requires that the new <stdarg.h> method be used for writing the body of
msg_get. A body using <varargs.h> will not match the ANSI C prototype,
while <stdarg.h> will not compile under Sun C.
It was necessary to choose between "char *" and "void *" for generic
pointers. In almost all cases I chose "void *". In ANSI C this has the
property of being compatible with any pointer. However casts were still
needed in many places to satisfy old C typechecking.
An apparent deficiency in the ANSI C standard is the lack of generality of
these "void *" coercions. Although "void *" is compatible with "int *",
the following two typedefs are not compatible:
typedef void (*func1)(void *arg)
typedef void (*func2)(int *arg)
ANSI C needs a proper notion of subtyping rather than the current ad hoc
compatibility rules.
A remaining problem is that at least one Sun header file (in Sunview) is
not compatible with the ANSI C-preprocessor. The problem is the use of
"#ifdef COMMENT ... #endif" to bracket large comments. Any apostophes count
as unmatched quotes according to ANSI C. Since gcc does not allow switching
to non-ANSI syntax for the duration of a single include file, it was
necessary to compile the sun_grid demo program with Sun C. This problem is
bound to arise with include files on other systems.
Once the ISIS header files were ANSI C compatible, it was straightforward
to make them usable from C++. The most significant change was replacing
global variable definitions in the header files by "extern" declarations
and putting the variable definition in the appropriate C file.
This recommended usage in C programs is enforced by AT&T C++. The other
change was handling the slightly different "typedef" syntax of C++.
Finally thanks to Alex Siegel and Pat Stephenson helping in this effort.
-- Robert Cooper