Re: Utility to ensure appropriate headers were included

On Sun, 24 Feb 2008 17:01:13 +0000, Richard Tobin wrote:
In article
<5649c69f-79d8-4e6f-a9a8-181b86a0f35c@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Tomás Ó hÉilidhe <toe@xxxxxxxxxxx> wrote:
Recently, there was a Linux program distributed as source code, and it
compiled fine on the majority of systems. However on some systems, it
failed to compile. On some of these systems, people were getting errors
for undeclared tokens, while others were getting linking errors.

Anyway, the problem was that one of the source files was missing:

#include <stdio.h>

This wasn't a problem on most systems because some of the other header
files that were included actually included stdio.h.

Presumably you mean that one of the system headers included stdio.h,
because if it was one of the program's headers this wouldn't be a
problem on "some systems".

I'm not sure to what extent this is permitted for standard C headers.

Not at all, except in specific cases under the as-if rule.

Presumably it's allowed, because all the identifiers they declare are
reserved. Perhaps someone can quote chapter and verse on this.

Most aren't reserved (except as external identifiers) unless the header is
included; part of 7.1.3p1 is:
"Each identifier with file scope listed in any of the following subclauses
(including the future library directions) is reserved for use as a macro
name and as an identifier with file scope in the same name space if any
of its associated headers is included."

This is a strictly conforming program:

#include <stdlib.h>
static int puts = 3;
int main(void) {
return puts - 3;
}

and it wouldn't work if <stdlib.h> includes <stdio.h>.

Is there any utility out there that will process a source file and
notify you if you're depending on a declaration that isn't present in a
header file that's included directly in the source file?

I don't think that's possible, since it's perfectly legal for, say,
stdio.h to work by including some other system headers that declares
printf().

Right.
.

Relevant Pages

  • Re: VS 2008
    ... In 'xml.cpp' file I moved the 'it' pointer out of for loop scope ... I did all these fixes for the VC9 build. ... idea if there could be conflicts with STL headers of VC9 with STL ... I don't have enough hd space now to test on this machine, but from your experience and mine, I'm guessing my xml solution would compile and run fine if 9.0 is orphaned from 7.1. ...
    (microsoft.public.vc.mfc)
  • Re: Redirect COUT to file
    ... The old headers are non-standard, ... compile and link this file. ... execute the exe-file the program crashes and I get this error message: ... //BUT NOT WITH CYGWIN G++ ...
    (comp.lang.cpp)
  • Re: Automatically generate variables
    ... use any non-standard stuff in its own headers. ... I did *not* say the program was strictly conforming. ... See, it does compile. ... We are not discussing quality of microsoft implementation, ...
    (comp.lang.c)
  • Re: hid.dll & VC++ 6
    ... VC6 is too old. ... Many of the headers in the current WDK will not compile ... missing ')' before identifier 'HIDP_REPORT_TYPE' ...
    (microsoft.public.win32.programmer.kernel)
  • Re: resolving linker errors
    ... You can remove them from the solution, and the project would still compile. ... That means they are checked out of source control when you modify them, and the make process will monitro changes on the files and automatically recompile all dependend source files. ... If you do not add the headers, changes in these headers might not cause the moduels using the header to be recompiled. ... project likely uses lots of .h files that are not listed in the Solution Explorer - standard library headers, Windows headers, perhaps third-party libraries. ...
    (microsoft.public.vc.language)