This is the mail archive of the
mailing list for the GCC project.
Re: script for `unincluding' header files (was Re: Patches to the FAQ and the fatal error messages for guiding bug-reports better)
- To: law at cygnus dot com, Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Subject: Re: script for `unincluding' header files (was Re: Patches to the FAQ and the fatal error messages for guiding bug-reports better)
- From: Robert Lipe <robertl at dgii dot com>
- Date: Mon, 31 Aug 1998 10:48:53 -0500
- Cc: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>, egcs-patches at cygnus dot com
- References: <email@example.com> <firstname.lastname@example.org>
> > I have written this script a while ago. Should I install it in the
> > contrib directory?
> Why do we need/want to "uninclude" stuff? Generally when I get a testcase
> I *want* a self-contained testcase including all the header files from
> the user's system.
In some cases, we absolutely _do_ want the users's system headers.
In others, we don't. For example, many of the C++ fragments in
g++.robertl/eb* were essentially five liners that happened to #include
something like stl.h ultimately that #included half the system headers.
Perhaps the bug we were exposing wasn't actually related to any of that,
but was an ICE for bogus parsing in the following four lines.
When I preprocessed them down to create testcases, we end up with things
like size_t or system protos being set "right" for _my_ system, but this
means that even when the ICE itself is fixed, these tests would fail on
systems with different size_t's. This has clearly caused people like
rth some grief when dragging the code to alpha where his size_t scoffs
at my puny 32 bit sizes. :-)
Like most such tools, it's up to the operator to know when to use them
and when not to use them.