[PATCH] gold: safe-ctype.h vs C++ system headers

[Roland McGrath <mcgrathr at google dot com>]

include/safe-ctype.h does majorly unkosher things with the system <ctype.h>
macros (is* and to*, in the C99 implementation name space).  This wreaks
havoc with anything #include'd after safe-ctype.h that tries to use the
<ctype.h> interfaces.  The system C++ headers might well be such things.
Having #include "safe-ctype.h" before any #include of a system header is
therefore unsafe.

This caused a build breakage for me when the host is a recent OSX version
with a recent OSX SDK.  There some C++ system headers #include <ctype.h>
and then use is* and/or to* interfaces in the implementation of some C++
interfaces.  Moving #include "safe-ctype.h" to where it's safely past
any other #include of a system header resolves the problem.  binary.cc
is the only place in gold that uses safe-ctype.h; its #include is after
the system headers used directly there, but some of the other gold header
files included by binary.cc include other C++ system headers, so
safe-ctype.h is only safe if it's definitely after all those.

OK for trunk, 2.26, and 2.25 branches?


Thanks,
Roland


gold/
2015-12-16  Roland McGrath  <mcgrathr@google.com>

	* binary.cc: Move #include "safe-ctype.h" to be last #include.

diff --git a/gold/binary.cc b/gold/binary.cc
index 12ca296..52df81a 100644
--- a/gold/binary.cc
+++ b/gold/binary.cc
@@ -24,7 +24,6 @@

 #include <cerrno>
 #include <cstring>
-#include "safe-ctype.h"

 #include "elfcpp.h"
 #include "stringpool.h"
@@ -32,6 +31,13 @@
 #include "output.h"
 #include "binary.h"

+// safe-ctype.h interferes with macros defined by the system <ctype.h>.
+// Some C++ system headers might include <ctype.h> and rely on its macro
+// definitions being intact.  So make sure that safe-ctype.h is included
+// only after any C++ system headers, whether directly here (above) or via
+// other local header files (e.g. #include <string> in "binary.h").
+#include "safe-ctype.h"
+
 // Support for reading binary files as input.  These become blobs in
 // the final output.  These files are treated as though they have a
 // single .data section and define three symbols: