Feeding back fixincludes changes

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

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?  (It's clearly desirable to fix the source of
the headers if possible, to avoid version skew between the original and
fixincluded headers.)

I believe that the fix made to ncurses's curses.h is bogus: it has (in
ncurses 5.2)

	#ifdef _XOPEN_SOURCE_EXTENDED
	#include <stddef.h>     /* we want wchar_t */
	#endif /* _XOPEN_SOURCE_EXTENDED */
...
	#ifdef _XOPEN_SOURCE_EXTENDED
	#ifndef _WCHAR_T
	typedef unsigned long wchar_t;
	#endif /* _WCHAR_T */

so it will never in fact try to declare wchar_t itself with GCC's
<stddef.h>.  In this case, should a change (what change) be sent to the
ncurses maintainer so that fixincludes understands that the header is OK,
or should fixincludes be taught that this particular header is OK?

Has anyone yet sent the changes fixincludes makes to the X headers to the
XFree86 maintainers?  (Are there any XFree86 developers on this list?)

In what is the fixincluding of glibc's <values.h> I noted earlier
(http://gcc.gnu.org/ml/gcc-bugs/2000-11/msg00720.html) a bug?

-- 
Joseph S. Myers
jsm28@cam.ac.uk