honor __WCHAR_TYPE__ on archs with legacy long definition of wchar_t
authorRich Felker <dalias@aerifal.cx>
Sun, 8 Sep 2019 21:33:48 +0000 (17:33 -0400)
committerRich Felker <dalias@aerifal.cx>
Sun, 8 Sep 2019 21:33:48 +0000 (17:33 -0400)
commit1f0e9f9cc2e3fa354f94e18b3b362de5f1ec7272
tree8c20ef31affe0b6dcb940c716a9cf76f74450ee0
parent8a544ee3a2a75af278145b09531177cab4939b41
honor __WCHAR_TYPE__ on archs with legacy long definition of wchar_t

historically, a number of 32-bit archs used long rather than int for
wchar_t, for no good reason. GCC still uses the historical types, but
clang replaced them all with int, and it seems PCC uses int too.
mismatching the compiler's type for wchar_t is not an option due to
wide string literals.

note that the mismatch does not affect C++ ABI since wchar_t is its
own builtin type/keyword in C++, distinct from both int and long, not
a typedef.

i386 already worked around this by honoring __WCHAR_TYPE__ if defined
by the compiler, and only using the official legacy ABI type if not.
add the same to the other affected archs.

it might make sense at some point to switch to using int as the
default if __WCHAR_TYPE__ is not defined, if the expectations is that
new compilers will treat int as the correct choice, but it's unlikely
that the case where __WCHAR_TYPE__ is undefined will ever be used
anyway. I actually wanted to move the definition of wchar_t to the
top-level shared alltypes.h.in, using __WCHAR_TYPE__ and falling back
to int if not defined, but that can't be done without assuming all
compilers define __WCHAR_TYPE__ thanks to some pathological archs
where the ABI has wchar_t as an unsigned type.
arch/m68k/bits/alltypes.h.in
arch/powerpc/bits/alltypes.h.in
arch/sh/bits/alltypes.h.in
arch/x32/bits/alltypes.h.in