Tool to determine which headers are needed/not_needed?

[C_guy]

Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed in
every .C file? This would be helpful in removing header inclusions
that are redundant and/or unnecessary.

Thanks!

[CBFalconer]

C_guy wrote:

>
Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed
in every .C file? This would be helpful in removing header
inclusions that are redundant and/or unnecessary.

Use your editor. Comment out a #include statement. Recompile. If
no errors appear, that statement can go. If errors appear, remove
the comment. Repeat.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Barry Schwarz]

On Wed, 10 Sep 2008 08:10:56 -0700 (PDT), C_guy <er*******@gmail.com>
wrote:

>Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed in
every .C file? This would be helpful in removing header inclusions
that are redundant and/or unnecessary.

If you start with none, the compiler will tell every time it
encounters something that would have been in a header. Add one at a
time till the diagnostics disappear.

Other than a pretty small time penalty, including an unnecessary
header or two usually doesn't cause problems.

--
Remove del for email

[Jack Klein]

On Wed, 10 Sep 2008 08:10:56 -0700 (PDT), C_guy <er*******@gmail.com>
wrote in comp.lang.c:

Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed in
every .C file? This would be helpful in removing header inclusions
that are redundant and/or unnecessary.

I see you've already got a few recommendations for the comment out and
look for errors school of thought, which does work but can take an
enormous amount of time for a large source code base.

The only tool that I know of that does this, and really well, is not
free. PC-Lint, http://www.gimpel.com. This feature is really a nice
little bonus. Its code checking function alone is worth many times
its price to anyone producing professional code.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[robertwessel2]

On Sep 10, 7:09*pm, CBFalconer <[e-mail]:

C_guy wrote:

Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed
in every .C file? *This would be helpful in removing header
inclusions that are redundant and/or unnecessary.

Use your editor. *Comment out a #include statement. *Recompile. *If
no errors appear, that statement can go. *If errors appear, remove
the comment. *Repeat.

Surely that's too simplistic - consider a header containing:

#undef FOO
#define FOO 17

Assuming a prior definition of FOO (to something other than 17), one
could easily see the compilation succeed, yet no longer be producing
the correct program).

Or a header that contains:

int a=1;

And everywhere else (possibly in the same compilation unit, if needed)
there's:

int a;

Many other potential problems exist

Which is not to say that sort of things is good programming practice
(and frankly most dependencies like that probably reflect poor
design), but we've all seen really bizarre stuff in headers, no?

[Flash Gordon]

ro***********@yahoo.com wrote, On 11/09/08 02:48:

On Sep 10, 7:09 pm, CBFalconer <[e-mail]:

>C_guy wrote:

>>Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed
in every .C file? This would be helpful in removing header
inclusions that are redundant and/or unnecessary.

Use your editor. Comment out a #include statement. Recompile. If
no errors appear, that statement can go. If errors appear, remove
the comment. Repeat.

Surely that's too simplistic - consider a header containing:

#undef FOO
#define FOO 17

Assuming a prior definition of FOO (to something other than 17), one
could easily see the compilation succeed, yet no longer be producing
the correct program).

Or a header that contains:

int a=1;

And everywhere else (possibly in the same compilation unit, if needed)
there's:

int a;

Many other potential problems exist

A far more likely potential problem in my opinion is if the header contains:
double foo(...)

Then with the default options on a lot of compilers (or with C89
conformance added to the defaults) the compiler will *not* complain, it
will just silently compiler the code with what is now undefined
behaviour which may or may not work. If foo currently returns an int it
is even worse, because then (if the parameters are not a problem) it
*will* work until foo() the return type of foo is changed.

Which is not to say that sort of things is good programming practice
(and frankly most dependencies like that probably reflect poor
design), but we've all seen really bizarre stuff in headers, no?

You don't need bizarre stuff in the header for commenting it out to
silently cause problems. Simple good practice can do it.

The OP would be well advised to ensure that the compiler is told to warn
about functions being called without a prototype in scope, and as much
else as possible. This will help catch problems where a header is *not*
included (directly or indirectly) but is needed. How to do this (and if
it is possible) is compiler dependant and so should be asked on a group
dedicated to the compiler.
--
Flash Gordon

[Ian Collins]

Jack Klein wrote:

On Wed, 10 Sep 2008 08:10:56 -0700 (PDT), C_guy <er*******@gmail.com>
wrote in comp.lang.c:

>Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed in
every .C file? This would be helpful in removing header inclusions
that are redundant and/or unnecessary.

I see you've already got a few recommendations for the comment out and
look for errors school of thought, which does work but can take an
enormous amount of time for a large source code base.

The only tool that I know of that does this, and really well, is not
free. PC-Lint, http://www.gimpel.com. This feature is really a nice
little bonus. Its code checking function alone is worth many times
its price to anyone producing professional code.

I hadn't looked before, but Sun Studio lint (which is free) also reports
unnecessary headers.

--
Ian Collins.

[Amandil]

On Sep 10, 8:09*pm, CBFalconer <[e-mail]:

C_guy wrote:

Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed
in every .C file? *This would be helpful in removing header
inclusions that are redundant and/or unnecessary.

Use your editor. *Comment out a #include statement. *Recompile. *If
no errors appear, that statement can go. *If errors appear, remove
the comment. *Repeat.

That won't necessarily accomplish what the OP is trying to do. For
example:
/* Begin file: */
#include <stdarg.h>

int main()
{
puts("Hello, World");
return EXIT_SUCCESS;
}
/* End of file */

The above program will flag exactly 1 error, EXIT_SUCCESS not having
been
#define'd. #include'ing <stdlib.hwill fix that. The OP wants this
tool to
remind him to also #include <stdio.h>, and notify him that <stdarg.h>
is
unnecessary. Compiling with -Wall (or whatever it is on other
compilers) will
_warn_ me about the missing declaration for puts() (Which I may or may
not remember
is in <stdio.h>), but it won't make a peep about the extra header.

Mr. Klein helpfully mentioned a tool which may help you.

-- Marty Amandil

[CBFalconer]

Amandil wrote:

CBFalconer <[e-mail]:

>C_guy wrote:

>>Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed
in every .C file? This would be helpful in removing header
inclusions that are redundant and/or unnecessary.

Use your editor. Comment out a #include statement. Recompile.
If no errors appear, that statement can go. If errors appear,
remove the comment. Repeat.

That won't necessarily accomplish what the OP is trying to do. For
example:
/* Begin file: */
#include <stdarg.h>

int main()
{
puts("Hello, World");
return EXIT_SUCCESS;
}
/* End of file */

The above program will flag exactly 1 error, EXIT_SUCCESS not
having been #define'd. #include'ing <stdlib.hwill fix that. The
OP wants this tool to remind him to also #include <stdio.h>, and
notify him that <stdarg.his unnecessary. Compiling with -Wall
(or whatever it is on other compilers) will _warn_ me about the
missing declaration for puts() (Which I may or may not remember
is in <stdio.h>), but it won't make a peep about the extra header.

No, C_guy wants to know what he can delete. Your suggestion above
will produce errors for the puts and the EXIT_SUCCESS usage.
Removing the include of stdarg.h will not affect that.

When something is undefined, most systems have an easy way to
access help on that item, which will specify the include file to
use. For example:

puts
====

Syntax
------
#include <stdio.h>

int puts(const char *string);

and you can always search the C standard for the same information.
The text version is very handy for this. Available (bzip2
compressed) at:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Thu, 11 Sep 2008 17:53:37 -0400, CBFalconer wrote:

Amandil wrote:

>CBFalconer <[e-mail]:

>>C_guy wrote:

Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed in
every .C file? This would be helpful in removing header inclusions
that are redundant and/or unnecessary.

Use your editor. Comment out a #include statement. Recompile. If no
errors appear, that statement can go. If errors appear, remove the
comment. Repeat.

That won't necessarily accomplish what the OP is trying to do. For
example:
/* Begin file: */
#include <stdarg.h>

int main()
{
puts("Hello, World");
return EXIT_SUCCESS;
}
/* End of file */

[snip]

No, C_guy wants to know what he can delete. [snip]

Fine, then given

/* Begin file: */
#include <stdio.h>

int main()
{
puts("Hello, World");
return 0;
}
/* End of file */

are you saying C_guy wants the inclusion of <stdio.hto go?

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:
[...]

and you can always search the C standard for the same information.
The text version is very handy for this. Available (bzip2
compressed) at:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

No, the C standard is not available as a text version.

n869_txt.bz2 is a pre-standard draft. n1256.pdf is the latest
post-standard draft, or the standard itself is available (but not
free) via ANSI or ISO.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard]

Keith Thompson <ks***@mib.orgwrites:

CBFalconer <cb********@yahoo.comwrites:
[...]

>and you can always search the C standard for the same information.
The text version is very handy for this. Available (bzip2
compressed) at:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

No, the C standard is not available as a text version.

n869_txt.bz2 is a pre-standard draft. n1256.pdf is the latest
post-standard draft, or the standard itself is available (but not
free) via ANSI or ISO.

You must have mentioned this to Chuckles about 1000 times by now. Please
stop replying to his SPAM and thus waking up threads he pollutes for the
rest of us.

[Flash Gordon]

CBFalconer wrote, On 11/09/08 22:53:

Amandil wrote:

>CBFalconer <[e-mail]:

>>C_guy wrote:

Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed
in every .C file? This would be helpful in removing header
inclusions that are redundant and/or unnecessary.
Use your editor. Comment out a #include statement. Recompile.
If no errors appear, that statement can go. If errors appear,
remove the comment. Repeat.

That won't necessarily accomplish what the OP is trying to do. For
example:
/* Begin file: */
#include <stdarg.h>

int main()
{
puts("Hello, World");
return EXIT_SUCCESS;
}
/* End of file */

The above program will flag exactly 1 error, EXIT_SUCCESS not
having been #define'd. #include'ing <stdlib.hwill fix that. The
OP wants this tool to remind him to also #include <stdio.h>, and
notify him that <stdarg.his unnecessary. Compiling with -Wall
(or whatever it is on other compilers) will _warn_ me about the
missing declaration for puts() (Which I may or may not remember
is in <stdio.h>), but it won't make a peep about the extra header.

No, C_guy wants to know what he can delete. Your suggestion above
will produce errors for the puts and the EXIT_SUCCESS usage.

Not if the OP is compiling with C89, the most commonly implemented
standard, or something close to C89 which is the most common default
mode for compilers. In such a situation there is no diagnostic required
for the call to puts. It is only with C99 the a diagnostic (which might
not be an error) is required.

Removing the include of stdarg.h will not affect that.

That was part of Amadil's point!

When something is undefined, most systems have an easy way to
access help on that item, which will specify the include file to
use. For example:

True but irrelevant. There is no requirement on the commonly implemented
standard to diagnose the lack of a declaration.

and you can always search the C standard for the same information.
The text version is very handy for this. Available (bzip2
compressed) at:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

Please at least tell people that is not any version of the standard and
where they can find something that does actually represent the standard.
It has been pointed out to you before that there are significant
differences.
--
Flash Gordon

[CBFalconer]

Harald van D?k wrote:

CBFalconer wrote:

.... snip ...

>

>No, C_guy wants to know what he can delete. [snip]

Fine, then given

/* Begin file: */
#include <stdio.h>

int main()
{
puts("Hello, World");
return 0;
}
/* End of file */

are you saying C_guy wants the inclusion of <stdio.hto go?

No, he wants to know if it CAN BE removed.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ben Bacarisse]

CBFalconer <cb********@yahoo.comwrites:

C_guy wrote:

>>
Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed
in every .C file? This would be helpful in removing header
inclusions that are redundant and/or unnecessary.

Use your editor. Comment out a #include statement. Recompile. If
no errors appear, that statement can go. If errors appear, remove
the comment. Repeat.

That does not work if a pair (or more) of include files need each
other but are (together) not needed by the rest of the code. This is
poor design, but a robust method should be able to detect it.
--
Ben.

[CBFalconer]

Ben Bacarisse wrote:

CBFalconer <cb********@yahoo.comwrites:

>C_guy wrote:

>>>
Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed
in every .C file? This would be helpful in removing header
inclusions that are redundant and/or unnecessary.

Use your editor. Comment out a #include statement. Recompile. If
no errors appear, that statement can go. If errors appear, remove
the comment. Repeat.

That does not work if a pair (or more) of include files need each
other but are (together) not needed by the rest of the code. This is
poor design, but a robust method should be able to detect it.

I believe this is not allowed with standard C system headers.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Richard Heathfield]

CBFalconer said:

Ben Bacarisse wrote:

<snip>

>That does not work if a pair (or more) of include files need each
other but are (together) not needed by the rest of the code. This is
poor design, but a robust method should be able to detect it.

I believe this is not allowed with standard C system headers.

What is the basis for your belief?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

C_guy wrote:

Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed in
every .C file? This would be helpful in removing header inclusions
that are redundant and/or unnecessary.

Thanks!

The lcc-win compiler will output all files included
in a given source file using the

lcc -M

option. If you collect this output in a series of files
you will (implicitely) obtain which files are NOT needed
since they will not appear in that list.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Nick Keighley]

On 11 Sep, 01:09, CBFalconer <[e-mail]:

C_guy wrote:

Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed
in every .C file? *This would be helpful in removing header
inclusions that are redundant and/or unnecessary.

Use your editor. *Comment out a #include statement. *Recompile. *If
no errors appear, that statement can go. *If errors appear, remove
the comment. *Repeat.

[-] Search for #include: (40261 results found in 9365 files)

--
Nick Keighley

[Keith Thompson]

jacob navia <ja***@nospam.comwrites:

C_guy wrote:

>Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed in
every .C file? This would be helpful in removing header inclusions
that are redundant and/or unnecessary.
Thanks!

The lcc-win compiler will output all files included
in a given source file using the

lcc -M

option. If you collect this output in a series of files
you will (implicitely) obtain which files are NOT needed
since they will not appear in that list.

I don't think that addresses the OP's question.

A concrete example:

#include <stdio.h>
#include <math.h>
int main(void)
{
puts("Hello, world");
return 0;
}

The OP is looking for a tool that will tell him that the
"#include <math.h>" is not needed.

lcc -M, if I understand it correctly, can tell you which headers are
not #include'd; it can't tell you which headers are #include'd
unnecessarily.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Keith Thompson wrote:

jacob navia <ja***@nospam.comwrites:

>The lcc-win compiler will output all files included
in a given source file using the

lcc -M

option. If you collect this output in a series of files
you will (implicitely) obtain which files are NOT needed
since they will not appear in that list.

I don't think that addresses the OP's question.

A concrete example:

#include <stdio.h>
#include <math.h>
int main(void)
{
puts("Hello, world");
return 0;
}

The OP is looking for a tool that will tell him that the
"#include <math.h>" is not needed.

lcc -M, if I understand it correctly, can tell you which headers are
not #include'd; it can't tell you which headers are #include'd
unnecessarily.

Like this:

lint -Nlevel /tmp/x.c

include file is unnecessary
(2) /usr/include/math.h

--
Ian Collins.

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Ben Bacarisse wrote:

<snip>

>>That does not work if a pair (or more) of include files need each
other but are (together) not needed by the rest of the code. This is
poor design, but a robust method should be able to detect it.

I believe this is not allowed with standard C system headers.

What is the basis for your belief?

I think I remember reading it in the C standard.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>CBFalconer said:

>>Ben Bacarisse wrote:

<snip>

>>>That does not work if a pair (or more) of include files need each
other but are (together) not needed by the rest of the code. This is
poor design, but a robust method should be able to detect it.

I believe this is not allowed with standard C system headers.

What is the basis for your belief?

I think I remember reading it in the C standard.

I can't find no reference to this claimed prohibition.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Richard Heathfield said:

CBFalconer said:

>Richard Heathfield wrote:

>>CBFalconer said:
Ben Bacarisse wrote:

<snip>

That does not work if a pair (or more) of include files need each
other but are (together) not needed by the rest of the code. This is
poor design, but a robust method should be able to detect it.

I believe this is not allowed with standard C system headers.

What is the basis for your belief?

I think I remember reading it in the C standard.

I can't find no reference to this claimed prohibition.

Oops. Two negatives make a positive, don't they? - and I'm *positive* that
I can't find no reference to this claimed prohibition.

Anyway - chapter & verse would be nice.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Richard Heathfield wrote:

>CBFalconer said:

>>Ben Bacarisse wrote:

<snip>

>>>That does not work if a pair (or more) of include files need each
other but are (together) not needed by the rest of the code. This is
poor design, but a robust method should be able to detect it.

I believe this is not allowed with standard C system headers.

What is the basis for your belief?

I think I remember reading it in the C standard.

I think what you mean is that none of the standard headers can have
this kind of relationship to each other.

But since header files that are part of the program *can* have such a
relationship, that's hardly relevant to what was being discussed.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Harald van =?UTF-8?b?RMSzaw==?=]

On Thu, 11 Sep 2008 20:03:07 -0400, CBFalconer wrote:

Harald van D?k wrote:

>CBFalconer wrote:

... snip ...

>>

>>No, C_guy wants to know what he can delete. [snip]

Fine, then given

/* Begin file: */
#include <stdio.h>

int main()
{
puts("Hello, World");
return 0;
}
/* End of file */

are you saying C_guy wants the inclusion of <stdio.hto go?

No, he wants to know if it CAN BE removed.

You managed to avoid the actual question.

/* Begin file: */
#include <stdio.h>
#include <stdlib.h>

int main()
{
puts("Hello, World");
return 0;
}
/* End of file */

Do you believe C_guy wants to have the same information for both headers?
I would imagine he wants to know that <stdlib.hcan be removed, and that
<stdio.hshould stay, even though it could be removed as well.

[CBFalconer]

Harald van D?k wrote:

CBFalconer wrote:

>Harald van D?k wrote:

>>CBFalconer wrote:

... snip ...

>>>
No, C_guy wants to know what he can delete. [snip]

Fine, then given

/* Begin file: */
#include <stdio.h>

int main() {
puts("Hello, World");
return 0;
}
/* End of file */

are you saying C_guy wants the inclusion of <stdio.hto go?

No, he wants to know if it CAN BE removed.

You managed to avoid the actual question.

No I didn't. I answered it with "No".

/* Begin file: */
#include <stdio.h>
#include <stdlib.h>

int main() {
puts("Hello, World");
return 0;
}
/* End of file */

Do you believe C_guy wants to have the same information for both
headers? I would imagine he wants to know that <stdlib.hcan be
removed, and that <stdio.hshould stay, even though it could be
removed as well.

No, stdio.h can't be omitted. Some compiler systems may not
object, but any C99 system should. If the compiler is sufficiently
poor it won't give any worthwhile information.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ron Ford]

On Wed, 10 Sep 2008 17:11:16 -0700, Barry Schwarz posted:

On Wed, 10 Sep 2008 08:10:56 -0700 (PDT), C_guy <er*******@gmail.com>
wrote:

>>Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed in
every .C file? This would be helpful in removing header inclusions
that are redundant and/or unnecessary.

If you start with none, the compiler will tell every time it
encounters something that would have been in a header. Add one at a
time till the diagnostics disappear.

Other than a pretty small time penalty, including an unnecessary
header or two usually doesn't cause problems.

With gcc, I had to add the -Wall flag to get it to tell me that I had left
a library unincluded.
--
When women kiss it always reminds one of prize fighters shaking hands.
H. L. Mencken

[Ron Ford]

On Fri, 12 Sep 2008 15:12:10 +0000, Richard Heathfield posted:

Richard Heathfield said:

>I can't find no reference to this claimed prohibition.

Oops. Two negatives make a positive, don't they? - and I'm *positive* that
I can't find no reference to this claimed prohibition.

Depends on the language.

German: Ich sehe nichts .
Russian: Ja veezhy nuchevo nyet.

These have the same meaning. Of course, I'm not the russian expert that
Sarah Palin is.

>
Anyway - chapter & verse would be nice.

Both germans and russians have wonderfully lyrical bibles.
--
The only cure for contempt is counter-contempt.
H. L. Mencken

[Harald van =?UTF-8?b?RMSzaw==?=]

On Fri, 12 Sep 2008 19:19:11 -0400, CBFalconer wrote:

Harald van D?k wrote:

> /* Begin file: */
#include <stdio.h>
#include <stdlib.h>

int main() {
puts("Hello, World");
return 0;
}
/* End of file */
[snip]

No, stdio.h can't be omitted. Some compiler systems may not object, but
any C99 system should. If the compiler is sufficiently poor it won't
give any worthwhile information.

Your initial answer was

"Use your editor. Comment out a #include statement. Recompile. If
no errors appear, that statement can go. If errors appear, remove
the comment. Repeat."

I will accept that "If no errors appear" means "If no errors or warnings
appear", and I might even be convinced that it means "If no errors or
warnings appear that hadn't appeared during the previous compilation", but
please explain how that works if the compiler is "sufficiently
poor" (where "sufficiently poor" includes C90-conforming implementations
that don't warn about correct use of C90 language constructs) and no
diagnostics of any kind are given when both #include lines are removed.

[Joachim Schmitz]

Ron Ford wrote:

On Wed, 10 Sep 2008 17:11:16 -0700, Barry Schwarz posted:

>On Wed, 10 Sep 2008 08:10:56 -0700 (PDT), C_guy <er*******@gmail.com>
wrote:

>>Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed in
every .C file? This would be helpful in removing header inclusions
that are redundant and/or unnecessary.

If you start with none, the compiler will tell every time it
encounters something that would have been in a header. Add one at a
time till the diagnostics disappear.

Other than a pretty small time penalty, including an unnecessary
header or two usually doesn't cause problems.

With gcc, I had to add the -Wall flag to get it to tell me that I had
left a library unincluded.

library != header file

Bye, Jojo

[Joachim Schmitz]

jacob navia wrote:

C_guy wrote:

>Does anyone know of a (hopefully free) tool that can traverse a
project and determine which "#include"s are not needed or needed in
every .C file? This would be helpful in removing header inclusions
that are redundant and/or unnecessary.

Thanks!

The lcc-win compiler will output all files included
in a given source file using the

lcc -M

Same switch in gcc, IIRC. Usefull to generate dependency lists for
Makefiles. But not for the pupose of the OP

option. If you collect this output in a series of files
you will (implicitely) obtain which files are NOT needed
since they will not appear in that list.

[Amandil]

On Sep 12, 10:53*am, CBFalconer <[e-mail]:

Richard Heathfield wrote:

CBFalconer said:

Ben Bacarisse wrote:

<snip>

>That does not work if a pair (or more) of include files need each
other but are (together) not needed by the rest of the code. *This is
poor design, but a robust method should be able to detect it.

I believe this is not allowed with standard C system headers.

What is the basis for your belief?

I think I remember reading it in the C standard.

What does the standard say about vfprintf()? I believe the standard
(or at least one of the free drafts of the standard) says to include
both <stdarg.hand <stdio.h(7.19.6.8) but the declaration of
vfprintf() needs to have <stdarg.hpreviously included. Although I
also remember reading something to that effect somewhere in the
standard (that one standard header not include another one) I don't
remember where.

-- Marty Amandil

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sun, 14 Sep 2008 10:43:16 -0700, Amandil wrote:

What does the standard say about vfprintf()? I believe the standard (or
at least one of the free drafts of the standard) says to include both
<stdarg.hand <stdio.h(7.19.6.8)

That's an understandable point of view. It says in 7.19.6.8p1 [The
vfprintf function / Synopsis]:

#include <stdarg.h>
#include <stdio.h>
int vfprintf(FILE * restrict stream,
const char * restrict format,
va_list arg);

which means that when you include both headers, the declaration of
vfprintf is equivalent to what has been stated. However, other
requirements also apply, and when you include <stdio.h(without
<stdarg.h>), then you must get a correct declaration of vfprintf. Since
va_list is then not defined (or perhaps defined by you, the programmer,
for something else?) <stdio.h>'s declaration of vfprintf must rely on
compiler or library internals, but it must work. So for example, if
<stdarg.hdefines va_list as a typedef for void *, then <stdio.hmust
declare int vfprintf(FILE *restrict, const char *restrict, void *);
without defining va_list.

[Nick Keighley]

On 12 Sep, 16:12, Richard Heathfield <[e-mail]:

Richard Heathfield said:

CBFalconer said:

Richard Heathfield wrote:
CBFalconer said:
Ben Bacarisse wrote:

><snip>

>>>That does not work if a pair (or more) of include files need each
other but are (together) not needed by the rest of the code. *This is
poor design, but a robust method should be able to detect it.

>>I believe this is not allowed with standard C system headers.

>What is the basis for your belief?

I think I remember reading it in the C standard.

I can't find no reference to this claimed prohibition.

Oops. Two negatives make a positive, don't they? - and I'm *positive* that
I can't find no reference to this claimed prohibition.

Anyway - chapter & verse would be nice.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999- Hide quoted text -

- Show quoted text -

[Richard Heathfield]

Nick Keighley said:

On 12 Sep, 16:12, Richard Heathfield <[e-mail]:

>Richard Heathfield said:

CBFalconer said:

>Richard Heathfield wrote:
CBFalconer said:
Ben Bacarisse wrote:

>><snip>

>>>>That does not work if a pair (or more) of include files need each
other but are (together) not needed by the rest of the code. This
is poor design, but a robust method should be able to detect it.

>>>I believe this is not allowed with standard C system headers.

>>What is the basis for your belief?

>I think I remember reading it in the C standard.

I can't find no reference to this claimed prohibition.

Oops. Two negatives make a positive, don't they? - and I'm *positive*
that I can't find no reference to this claimed prohibition.

Anyway - chapter & verse would be nice.

- Show quoted text -

Thanks for the heads-up, Nick.

:-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

vi******@gmail.com said:

On Sep 15, 1:20 pm, Richard Heathfield <[e-mail]:

<snip>

>I see no reason why [4.1.2 line 29] precludes <stddef.hfrom being
included by, say, <stdio.hand <stdio.hby <stddef.h>.

See DR #284
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_284.htm>

Quote:

>Committee Response

No Standard library header includes another Standard library header.
The header <math.hdoes not define INT_MIN or INT_MAX. A program that
wants to check the return value for equality with one of these macros
must include <limits.h>.

I think that makes it pretty clear that a std header can't include
another.

In my /usr/include, I have <stddef.hincluded by <locale.h>, <stdio.h>,
<stdlib.h>, <string.h>, and <time.h>. I have checked one of these headers
(<string.h>, as it happens) to see if its inclusion is conditional on
being invoked in non-conforming mode, and it doesn't appear to be.

So either you're wrong - which is possible - and the Committee is wrong -
which is unlikely, or the "as if" rule applies - which is probable, and in
which case a standard library header /can/ include another standard
library header, as long as it doesn't look like it - or the implementation
is non-C90-conforming - which is unlikely.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[vippstar]

On Sep 15, 6:26 pm, Richard Heathfield <[e-mail]:

[e-mail] said:

>On Sep 15, 1:20 pm, Richard Heathfield <[e-mail]:

>>I see no reason why [4.1.2 line 29] precludes <stddef.hfrom being
included by, say, <stdio.hand <stdio.hby <stddef.h>.

>See DR #284
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_284.htm>

>Quote:

>>Committee Response

>>No Standard library header includes another Standard library header.
The header <math.hdoes not define INT_MIN or INT_MAX. A program that
wants to check the return value for equality with one of these macros
must include <limits.h>.

>I think that makes it pretty clear that a std header can't include
another.

In my /usr/include, I have <stddef.hincluded by <locale.h>, <stdio.h>,
<stdlib.h>, <string.h>, and <time.h>. I have checked one of these headers
(<string.h>, as it happens) to see if its inclusion is conditional on
being invoked in non-conforming mode, and it doesn't appear to be.

So either you're wrong - which is possible - and the Committee is wrong -
which is unlikely, or the "as if" rule applies - which is probable, and in
which case a standard library header /can/ include another standard
library header, as long as it doesn't look like it - or the implementation
is non-C90-conforming - which is unlikely.

Perhaps with those words

>>No Standard library header includes another Standard library header.

the Committee means

>>No Standard library header [is required to include] another Standard library header.

Because I can not find anything in the C standard that explicity
forbids std header files to include other std header files.
I'm curious though, so I think I'll follow whatever discussion for
this matter.