Re: Some particular lint problem

dab@myrias.com (Danny Boulet)
Mon, 11 Jun 90 21:43:58 GMT

          From comp.compilers

Related articles
Some particular lint problem pr@fctunl.rccn.pt (1990-06-07)
Re: Some particular lint problem pardo@cs.washington.edu (1990-06-08)
Re: Some particular lint problem dab@myrias.com (1990-06-11)
| List of all articles for this month |
Newsgroups: comp.compilers
From: dab@myrias.com (Danny Boulet)
References: <1990Jun7.010930.2167@esegue.segue.boston.ma.us>
Date: Mon, 11 Jun 90 21:43:58 GMT
Organization: Myrias Research Corporation
Keywords: C, lint

In article <1990Jun7.010930.2167@esegue.segue.boston.ma.us> pr@fctunl.rccn.pt (Paulo Rosado) writes:
>I was given this medium-size system with about 15 *.c modules and respective
>*.h ones, to extend. The program was developed in an incremental not nicely
>way so _every_ c module includes _every_ h file. I want to rearrange this and
>define exactly what is defined/used by whom, at least, in order to get a
>better profit from the make utility.
>


The simplest way to determine if a ".c" file needs a particular ".h" file is
to try compiling the ".c" file without the ".h" file. It shouldn't be very
hard to build a checker that does this. For example, consider:


        #include <a.h>
        #include "b.h"
        #include <sys/d.h>


        void
        funky() ...


The checker would delete "#include <a.h>" and invoke the C compiler sending
all output to /dev/null. If the exit code from the compile is zero then that
include file isn't needed. If it is non-zero, then it is. This process
would be repeated for each ".h" file.


If each file contains a lot of include files then this might take a while.
15 "c." and ".h" modules shouldn't take that long to process.


-Danny (kludge) Boulet :-)> dab@myrias.com
[Not very reliable, since undefined macros with arguments look just like
external functions that won't be determined to be missing until link
time. -John]
--


Post a followup to this message

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