This is the mail archive of the
mailing list for the binutils project.
[PATCH] gold: safe-ctype.h vs C++ system headers
- From: Roland McGrath <mcgrathr at google dot com>
- To: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 16 Dec 2015 13:33:42 -0800
- Subject: [PATCH] gold: safe-ctype.h vs C++ system headers
- Authentication-results: sourceware.org; auth=none
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
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?
2015-12-16 Roland McGrath <email@example.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
@@ -24,7 +24,6 @@
@@ -32,6 +31,13 @@
+// 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").
// 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: