Tool to determine which headers are needed/not_needed?

[CBFalconer]

CBFalconer said:

What is the basis for your belief?

I think I remember reading it in the C standard.

 

[Keith Thompson]

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.

 

[Harald van Dijk]

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.h> to 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.h> can be removed, and that
<stdio.h> should stay, even though it could be removed as well.

 

[John Bode]

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!

AFAIK none exists, because it's an absolute bitch of a problem in the
general case. It's one of those things that sounds like a good idea,
but as you start getting into it and analyzing some of the edge cases
it turns out to be more effort than it's worth.

 

[Ian Collins]

AFAIK none exists, because it's an absolute bitch of a problem in the
general case.

Then how comes lint does it?

 

[CBFalconer]

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.h> to 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.h> can be
removed, and that <stdio.h> should 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.

 

[Ron Ford]

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.

 

[Ron Ford]

Richard Heathfield said:

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.

 

[Harald van Dijk]

/* 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]

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]

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

 

[Amandil]

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.h> and <stdio.h> (7.19.6.8) but the declaration of
vfprintf() needs to have <stdarg.h> previously 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 Dijk]

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.h> and <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.h> defines va_list as a typedef for void *, then <stdio.h> must
declare int vfprintf(FILE *restrict, const char *restrict, void *);
without defining va_list.

 

[Nick Keighley]

Richard Heathfield said:







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 -

 

[Nick Keighley]

Richard Heathfield said:


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.

I *think* this bit

***
AMERICAN NATIONAL STANDARD X3.159-1989

para 4.1.2
Standard Headers
[...]
line 29
Headers may be included in any order; each may be included
more than once in a given scope, with no effect different from
being included only once,
[except <assert.h> is funny]
***

So I don't see how one header can be dependent on another.

Plauger (in his standard library book) descibes standard headers
as being "idempotent" IIRC.


--
Nick Keighley

All right, but apart from the sanitation, the medicine,
education,
wine, public order, irrigation, roads, a fresh water system, and
public health, what have the Romans ever done for us?

 

[Ben Bacarisse]

Nick Keighley said:

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

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.

I *think* this bit

***
AMERICAN NATIONAL STANDARD X3.159-1989

para 4.1.2
Standard Headers
[...]
line 29
Headers may be included in any order; each may be included
more than once in a given scope, with no effect different from
being included only once,
[except <assert.h> is funny]
***

So I don't see how one header can be dependent on another.

I see no reason why the above paragraph precludes <stddef.h> from being
included by, say, <stdio.h> and <stdio.h> by <stddef.h>.

Has the issue drifted? I am having trouble seeing relevance.

I originally posted about the case of two headers being required by
each other (but not by the code). I don't think this can occur with
standard headers, though I can't say why except that I can't think of
even one standard header that requires another.

I don't think Nick Keighley's quote is enough on its own but it raises
the bar -- the two headers would have to be mutually dependent and
this would have to be the case in either order. I can't think of how
this could occur but that is not a proof.

 

[John Bode]

Then how comes lint does it?

Obviously because lint is smarter than I am.

 

[vippstar]

Nick Keighley said:

I *think* this bit

***
AMERICAN NATIONAL STANDARD X3.159-1989

para 4.1.2
Standard Headers
[...]
line 29
Headers may be included in any order; each may be included
more than once in a given scope, with no effect different from
being included only once,
[except <assert.h> is funny]
***

So I don't see how one header can be dependent on another.

I see no reason why the above paragraph precludes <stddef.h> from being
included by, say, <stdio.h> and <stdio.h> by <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.h> does 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.

 

[vippstar]

(e-mail address removed) said:

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

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

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

In my /usr/include, I have <stddef.h> included 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
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.