summaryrefslogtreecommitdiff
path: root/arch/i386
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2011-06-07 11:26:42 -0400
committerRich Felker <dalias@aerifal.cx>2011-06-07 11:26:42 -0400
commit0b6b43ed3fd26cf8cd926193be5c9fd831b534c4 (patch)
tree32c878f70b8b996ef69f6b0f7efbfdaf2a5bc74b /arch/i386
parent86f8c72bb1cc1fad05e1ed1b2a6f4433defc9cf7 (diff)
downloadmusl-0b6b43ed3fd26cf8cd926193be5c9fd831b534c4.tar.gz
use __WCHAR_TYPE__ on i386 if it is defined
unfortunately traditional i386 practice was to use "long" rather than "int" for wchar_t, despite the latter being much more natural and logical. we followed this practice, but it seems some compilers (clang and maybe certain gcc builds or others too..?) have switched to using int, resulting in spurious pointer type mismatches when L"..." wide strings are used. the best solution I could find is to use the compiler's definition of wchar_t if it exists, and otherwise fallback to the traditional definition. there's no point in duplicating this approach on 64-bit archs, as their only 32-bit type is int.
Diffstat (limited to 'arch/i386')
-rwxr-xr-xarch/i386/bits/alltypes.h.sh4
1 files changed, 4 insertions, 0 deletions
diff --git a/arch/i386/bits/alltypes.h.sh b/arch/i386/bits/alltypes.h.sh
index 335c0957..672d6a45 100755
--- a/arch/i386/bits/alltypes.h.sh
+++ b/arch/i386/bits/alltypes.h.sh
@@ -26,7 +26,11 @@ TYPEDEF __builtin_va_list va_list;
TYPEDEF struct __va_list * va_list;
#endif
+#ifdef __WCHAR_TYPE__
+TYPEDEF __WCHAR_TYPE__ wchar_t;
+#else
TYPEDEF long wchar_t;
+#endif
TYPEDEF long wint_t;
TYPEDEF long wctrans_t;
TYPEDEF long wctype_t;