mirror of git://git.musl-libc.org/musl
1f0e9f9cc2
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. |
||
|---|---|---|
| .. | ||
| aarch64 | ||
| arm | ||
| generic | ||
| i386 | ||
| m68k | ||
| microblaze | ||
| mips | ||
| mips64 | ||
| mipsn32 | ||
| or1k | ||
| powerpc | ||
| powerpc64 | ||
| riscv64 | ||
| s390x | ||
| sh | ||
| x32 | ||
| x86_64 | ||