Inter-module type checking for C (was: A lesson for ...)

In article 92-06-084 Arnold Robbins writes:
>[C compilers don't catch type mismatches in separately compiled modules.]


I'd like to make two points here.


First, while Arnold's criticism is essentially valid, it is (I feel)
somewhat misdirected. It is not the job of a C compiler do do the kind of
inter-compilation-unit checking which would be needed to catch this kind
of programming error. Rather, one might more properly say that it would
be "nice" (or perhaps even essential) for a "compilation system" to do
this kind of checking.


I use the term "compilation system" rather than "compiler" because I
really think that a separate element of the overall compilation system
(i.e. the linker) is the more reasonable tool in which to implement this
kind of inter-compilation-unit type checking.


It is unfortunate that current linkers do not do this kind of checking,
but (in my opinion) it is simply a matter of time before commonly
available linkers will implement such a feature.


This functionality would obviously require the presence of detailed type
information within individual object files (i.e. .o files). Note however
that such information may already be present in object files which have
been generated by commonly available compilers when the -g option is used
(to generate symbolic debugging information). Thus, it is just a matter
of getting linkers to use this information to do cross-module type
checking.


(Well OK. To tell the truth, it is actually slightly more complicated
than that. The sad fact is that even when the -g option is used, most C
compilers fail to generate *any* symbolic debugging information for
functions and variables which are merely declared as externals within the
current compilation unit. This critical ommision makes it impossible to
use the symbolic debugging information to do link-time inter-module type
checking even for such simple examples as the one which Arnold gave. The
good news however is that the UNIX International Programming Languages
Special Interest Group (aka UI/PLSIG) is working on a draft specification
for DWARF Version 2, and in version 2 of DWARF we expect to specify that
DWARF type information for all external function and variable declarations
which are actually referenced somewhere within the current compilation
unit should be generated and placed into the .o file. This change will
make it possible to implement link-time type checking for C, C++, Fortran
and other languages based upon DWARF symbolic debugging information.)




The second point I wanted to make was that the kinds of simple inter-
module typing errors which Arnold's example illustrated can be easily
eliminated via strict adherence to one simple (and reasonable) coding
guideline for either C or C++, and via the use of a good C compiler like
GCC.


The coding guideline I'm speaking of is just this. Never put any `extern'
declarations in .c files... always put them into .h files (where they
belong).


Using this coding rule, together with GCC's -Wimplicit option can totally
eliminate inter-compilation-unit type errors in C code.


Allow me to explain...


GCC's -Wimplicit option causes GCC to generate warnings for all cases
where a function is not explicitly declared before it is called. If one
uses this compilation opinion, and then also works over one's code until
all such warnings have been eliminated (while placing any needed explicit
function declarations into the .h files where they belong) then eventually
you will reach a state of "code quality" where there simply cannot be any
remaining inter-compilation unit typing errors.


(For existing code such as Arnold's example above, we would have begun
this "quality introduction" program by grepping the .c files for the
string "extern" and moving all such declarations into .h files. Then we
would add #include directives into the .c files, as necessary, until all
of the -Wimplicit warnings were totally eliminated. Simple, no?)
--


// Ron ("Loose Cannon") Guilmette
// Internet: rfg@ncd.com uucp: ...uunet!ncd.com!rfg
[You could still lose if you forget to include the .h file in the .c file
that declares the function, but in general it's certainly true that if you
use prototypes your compiler will point out type mismatches. -John]
--

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