Feeding back fixincludes changes

[Bruce Korb]

"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.  :-)