Andrew Dunstan <[EMAIL PROTECTED]> writes: > I agree with reverting. The tool looks pretty broken anyway, with > hardcoded paths and all sorts of stuff quite apart from logic problems.
Well, it's only intended to work on Bruce's system, so until someone else takes over the position of chief gruntwork-doer I don't think the portability issues are much of a factor. What I'm worried about at the moment is the correctness issue. After some reflection it seems that there is only one case where removal of a needed include file would not lead to a compiler error or warning, assuming gcc with ordinary -W settings (notably -Wmissing-prototypes). That case is exactly what Kris found: removal of a #define that is tested via #ifdef or #if defined(). (Can anyone think of other cases?) It's not hard to imagine getting burnt by this through ordinary manual rearrangement or cleanup of inclusions, so I'm thinking that blaming pgrminclude may be too hasty. It'd be worth our time to make a tool to check for it. I'm going to work on a Perl script that sucks up all the #defines in all our .h files and looks for "#ifdef foo" or "defined foo" where foo is defined in a file not included by the referencing file (gcc -H looks like the right tool for checking that). Another thing such a script could easily do is check for inclusion of system headers before c.h. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster