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

Raul Deluth Miller-Rockwell <rockwell@socrates.umd.edu>
Mon, 22 Jun 1992 01:43:40 GMT

          From comp.compilers

Related articles
Inter-module type checking for C (was: A lesson for ...) rfg@ncd.com (1992-06-19)
Re: Inter-module type checking for C (was: A lesson for ...) rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) (1992-06-22)
Re: Inter-module type checking for C (was: A lesson for ...) rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) (1992-06-22)
Re: Inter-module type checking for C (was: A lesson for ...) ian@airs.com (1992-06-22)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Raul Deluth Miller-Rockwell <rockwell@socrates.umd.edu>
Keywords: C, lint
Organization: Compilers Central
References: <19920609091040SEB1525@MVS.draper.com> 92-06-094
Date: Mon, 22 Jun 1992 01:43:40 GMT

Ron Guilmette:
      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).


      [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]


Another thing you can do, if you can live with the increased compile
times, is use the #include system with conditional compilation to run a
consistency check pass.


Basically, you have one .h file which defines a few macros, includes all
the .c file, then undefs/redefs the macros. Your macros are set up to
give extern declarations the first time around and complete declarations
afterwards.


This takes a little getting used to, and you'll probably have to tweak
your coding tools to deal with the altered syntax. But when you're
stream-of-thought coding in C it's a decent way of getting heavy duty type
checking out of C.


If you need the compilation speed, you could take code written in this
style and extract a more traditional .h/.c configuration. [Optimizing
compiler speed at the expense of design speed. Or sometimes you have to
do this to get reasonable error messages out of the compiler.]


--
Raul Deluth Miller-Rockwell <rockwell@socrates.umd.edu>
--


Post a followup to this message

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