«

Hi All,

Does anyone know of a tool that can automatically analyze C source to
remove unused #includes?

Thanks,
Sean

In article <. com>,
<> wrote:

>Does anyone know of a tool that can automatically analyze C source to
>remove unused #includes?

Tricky.

A #define in include1.h might be used in a #define in include2.h that
might be used to build a type in include3.h that might be needed by a
function declaration brought in by include5.h that is #include'd by
include4.h, and the function name might be in a disguised array
initialization form in include6.h and the analyzer would have to
analyze your source to see whether you refer to that function directly
or if you use the array initialization...

In other words, such a tool would have to pretty much be a C compiler
itself, but one that kept track of all the "influences" that went
to build up every token, and figured out what wasn't used after-all.

It might be easier just to start commenting out #include's and
seeing if any compile problems came up.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer

On Fri, 20 Oct 2006 17:39:25 +0000 (UTC), Walter Roberson wrote:
> <> wrote:
>>Does anyone know of a tool that can automatically analyze C source to
>>remove unused #includes?
>
>It might be easier just to start commenting out #include's and
>seeing if any compile problems came up.

Automate that and you have the requested tool!

Best wishes,
Roland Pibinger

In article <>,
Roland Pibinger <> wrote:
>On Fri, 20 Oct 2006 17:39:25 +0000 (UTC), Walter Roberson wrote:
>> <> wrote:
>>>Does anyone know of a tool that can automatically analyze C source to
>>>remove unused #includes?

>>It might be easier just to start commenting out #include's and
>>seeing if any compile problems came up.

>Automate that and you have the requested tool!

including a particular file can end up changing the meaning of
something else, but the code might compile fine without it.

For example, you might have an include file that contained

#define _use_search_heuristics 1

Then the code might have

#if defined(_use_search_heuristics)
/* do it one way */
#else
/* do it a different way */
#endif

where the code is valid either way.

Thus in order to test whether any particular #include is really
needed by checking the compile results, you need to analyze the
compiled object, strip out symbol tables and debug information and
compile timestamps and so on, and compare the generated code.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

On Fri, 20 Oct 2006 19:47:42 +0000 (UTC), Walter Roberson wrote:
>including a particular file can end up changing the meaning of
>something else, but the code might compile fine without it.
>
>For example, you might have an include file that contained
>
> #define _use_search_heuristics 1
>
>Then the code might have
>
> #if defined(_use_search_heuristics)
> /* do it one way */
> #else
> /* do it a different way */
> #endif
>
>where the code is valid either way.

You are right in theory. But that kind of include file dependencies
(include order dependencies) is usally considered bad style.

>Thus in order to test whether any particular #include is really
>needed by checking the compile results, you need to analyze the
>compiled object, strip out symbol tables and debug information and
>compile timestamps and so on, and compare the generated code.

IMO, this is overdone. You have to test your application after code
changes anyway.

Best regards,
Roland Pibinger

On Fri, 20 Oct 2006 20:30:35 GMT, (Roland Pibinger)
wrote:

>On Fri, 20 Oct 2006 19:47:42 +0000 (UTC), Walter Roberson wrote:
>>including a particular file can end up changing the meaning of
>>something else, but the code might compile fine without it.
>>
>>For example, you might have an include file that contained
>>
>> #define _use_search_heuristics 1
>>
>>Then the code might have
>>
>> #if defined(_use_search_heuristics)
>> /* do it one way */
>> #else
>> /* do it a different way */
>> #endif
>>
>>where the code is valid either way.
>
>You are right in theory. But that kind of include file dependencies
>(include order dependencies) is usally considered bad style.

No, he's right in practice. There's no guarantee that a body of
existing code will conform to your (or anyone's) rules of good style.
>
>>Thus in order to test whether any particular #include is really
>>needed by checking the compile results, you need to analyze the
>>compiled object, strip out symbol tables and debug information and
>>compile timestamps and so on, and compare the generated code.
>
>IMO, this is overdone. You have to test your application after code
>changes anyway.
>
>Best regards,
>Roland Pibinger

--
Al Balmer
Sun City, AZ

In article <>,
Roland Pibinger <> wrote:
>On Fri, 20 Oct 2006 19:47:42 +0000 (UTC), Walter Roberson wrote:

>>including a particular file can end up changing the meaning of
>>something else, but the code might compile fine without it.

>>For example, you might have an include file that contained
>> #define _use_search_heuristics 1
>>Then the code might have
>> #if defined(_use_search_heuristics)
>> /* do it one way */
>> #else
>> /* do it a different way */
>> #endif
>>where the code is valid either way.

>You are right in theory. But that kind of include file dependencies
>(include order dependencies) is usally considered bad style.

It happens often with large projects with automakes and
system dependancies. The included file that changes the meaning
of the rest is a "hints" file.

For example, on the OS I use most often, for a well
known large project (perl as I recall) the autoconfigure
detects that the OS has library entries and include entries
for a particular feature. Unfortunately that particular feature
doesn't work very well in the OS -- broken -and- very inefficient.
So the OS hints file basically says, "Yes I know you've detected
that, but don't use it." So the large project goes aheads and
compiles in the code that performs the task using more standardized
system calls instead of the newer less-standardized API.

>IMO, this is overdone. You have to test your application after code
>changes

Conformance tests can take 3 days per build, and if you
are checking whether a project with 1500 #includes (distributed
over the source) can survive deleting one particular include
out of one particular module, then you need up to pow(2,1500)
complete builds and conformance tests. Even if each *complete*
application conformance test took only 1 second, it'd take
10^444 CPU years to complete the testing. *Much* faster to break
it into chunks (e.g., by source file) and check to see whether
each chunk still produces the same code after removal of a
particular include: the timing then becomes proportional to
the sum of pow(2,includes_in_this_chunk) instead of the product
of those as would be the case with what you propose.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

Walter Roberson wrote:
> Conformance tests can take 3 days per build, and if you
> are checking whether a project with 1500 #includes (distributed
> over the source) can survive deleting one particular include
> out of one particular module, then you need up to pow(2,1500)
> complete builds and conformance tests. Even if each *complete*
> application conformance test took only 1 second, it'd take
> 10^444 CPU years to complete the testing. *Much* faster to break
> it into chunks (e.g., by source file) and check to see whether
> each chunk still produces the same code after removal of a
> particular include: the timing then becomes proportional to
> the sum of pow(2,includes_in_this_chunk) instead of the product
> of those as would be the case with what you propose.

That is a good idea: selectively removing #include statements, and then
simply seeing if the resulting object code file changes.

Otherwise, a customized C compiler could absolutely tell if there were
any dependencies on a particular #include file.

"Walter Roberson" <> wrote in message news:ehb94u$8gn$...
> In article <>,
> Roland Pibinger <> wrote:
>>On Fri, 20 Oct 2006 17:39:25 +0000 (UTC), Walter Roberson wrote:
>>> <> wrote:
>>>>Does anyone know of a tool that can automatically analyze C source to
>>>>remove unused #includes?
>
>>>It might be easier just to start commenting out #include's and
>>>seeing if any compile problems came up.
>
>>Automate that and you have the requested tool!
>
> including a particular file can end up changing the meaning of
> something else, but the code might compile fine without it.
>
> For example, you might have an include file that contained
>
> #define _use_search_heuristics 1
>
> Then the code might have
>
> #if defined(_use_search_heuristics)
> /* do it one way */
> #else
> /* do it a different way */
> #endif
>
> where the code is valid either way.
>
> Thus in order to test whether any particular #include is really
> needed by checking the compile results, you need to analyze the
> compiled object, strip out symbol tables and debug information and
> compile timestamps and so on, and compare the generated code.

Then, analyze it to make sure you don't delete the #include of "seems_unused.h" in this:

seems_unused.h:
-----------------
#define MIGHT_NEED 1

somefile.c:
----------
#ifdef DEFINED_WITH_MINUS_D
int var = MIGHT_NEED;
#endif

-- so that next week, when somebody does gcc -DDEFINED_WITH_MINUS_D, the code still builds.

wrote:
> Hi All,
>
> Does anyone know of a tool that can automatically analyze C source to
> remove unused #includes?
>
> Thanks,
> Sean
>

doesn't PC-LINT give you a list of unused includes?