This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Feeding back fixincludes changes
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Subject: Re: Feeding back fixincludes changes
- From: Bruce Korb <bkorb at sco dot COM>
- Date: Wed, 29 Nov 2000 12:17:08 -0800
- CC: gcc at gcc dot gnu dot org
- Organization: The Santa Cruz Operation
- References: <Pine.LNX.4.30.0011291924430.10928-100000@kern.srcf.societies.cam.ac.uk>
- Reply-To: Bruce Korb <bkorb at cruzio dot com>
"Joseph S. Myers" wrote:
>
> If fixincludes makes changes to headers from free software libraries, I
> take it that the changes (if genuine) should be sent to the maintainer of
> the library in question so that they can fix future releases so that they
> no longer need to be or get fixincluded?
>
> In particular, for the wchar_t changes: if the header (in its originating
> free software package) gets #ifndef __cplusplus added around the bogus
> definition of wchar_t, will this suffice to prevent fixincludes from
> fixing the header in future?
No :-(. There are headers that contain "__cplusplus" but do
not protect wchar_t with that. If someone has the time to write
C-code version of a wchar_t tester, however, they can write the
code that finds the typedef and backs up to the previous line
to check for a #ifdef. I don't have the time myself. Sorry. :-(
> (It's clearly desirable to fix the source of
> the headers if possible, to avoid version skew between the original and
> fixincluded headers.)
I have an amusing idea. There was a similar problem with
fixinc fixing:
/*
bool_t (*xp_getargs)(); -- get arguments
*/
getting "fixed" despite the fact that it was in a comment.
The maintainer of the rpc headers added a space between the ``()''
chars to avoid the hackup. It was just too hard to figure out
that this construct was inside of a comment.
Here is what I propose:
Since it is not necessarily even possible to figure out
if wchar_t has been properly wrapped for C++ inclusion,
I propose that _every_ fixinclude fix check for the string:
fixinc-mumble-ok
where ``mumble'' is the hack name. Therefore,
if there is no easy way to determine if the header is mumble-safe,
the header maintainer can declare the file to be mumble-safe
with a little comment at the end of the header. Naturally, it
would be preferable to have a test to determine mumble-safeness.
It just is not always easy to do. :-)