This is the mail archive of the
mailing list for the GCC project.
Re: aggressive fixincludes
- To: ddsinc09 at ix dot netcom dot com, korbb at sourceware dot cygnus dot com
- Subject: Re: aggressive fixincludes
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 23 Nov 1999 11:25:55 -0800
- Cc: gcc at gcc dot gnu dot org, autogen at linuxbox dot com
- Organization: CodeSourcery, LLC
- References: <firstname.lastname@example.org>
>>>>> "korbb" == korbb <email@example.com> writes:
korbb> Sure. Tell me how to identify the fact that "FlexLexer.h"
korbb> is a C++ file. Were it, "FlexLexer.H" or "FlexLexer.h++"
korbb> or just about anything except "*.h", then it would be
korbb> ignored. At the same time, I do not think it crucial that
korbb> the comments remain. After all, they _are_ comments and
korbb> /usr/include/FlexLexer.h still remains in /usr/include for
korbb> visual reference. Please, propose a solution.
One thing I am concerned about is that fixincluded files to not get
updated when packages get updated. So, to prevent skew, we should
keep the number of fixincluded files to a minimum, even if the fixes
do not in any way break the file. Also, in C++, you can step into
code in header files; it's bad if the header is missing its comments.
As for a solution, finding an `extern "C++"' is a good hint it's not C
file. (`extern "C"' might appear in a C header that can be included
from C++, but `extern "C++"' is much less likely.) That would cover
And anything in /usr/include/g++* (g++,g++-2,g++-3) should be excluded
from this test, as those are C++ files.
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com