this type was removed back in 5243e5f1 ,
because it was removed from the XSI specs.
however some apps use it.
since it's in the POSIX reserved namespace, we can expose it
unconditionally.

wctype_t was incorrectly "int" rather than "long" on x86_64. not only
is this an ABI incompatibility; it's also a major design flaw if we
ever wanted wctype_t to be implemented as a pointer, which would be
necessary if locales support custom character classes, since int is
too small to store a converted pointer. this commit fixes wctype_t to
be unsigned long on all archs, matching the LSB ABI; this change does
not matter for C code, but for C++ it affects mangling.

the same issue applied to wctrans_t. glibc/LSB defines this type as
const __int32_t *, but since no such definition is visible, I've just
expanded the definition, int, everywhere.

it would be nice if these types (which don't vary by arch) could be in
wctype.h, but the OB XSI requirement in POSIX that wchar.h expose some
types and functions from wctype.h precludes doing so. glibc works
around this with some hideous hacks, but trying to duplicate that
would go against the intent of musl's headers.

this is needed to match the underlying "ABI" standards. it's not
really an ABI issue since the binary representations are the same, but
having the wrong type can lead to errors when the type arising from a
difference-of-pointers expression does not match the defined type of
ptrdiff_t. most of the problems affect C++, not C.

otherwise this BADLY breaks if -funsigned-char is passed to gcc

it's a keyword in c++ (wtf). i'm not sure this is the cleanest
solution; it might be better to avoid ever defining __NEED_wchar_t on
c++. but in any case, this works for now.

really wchar_t should never vary, but the ARM EABI defines it as an
unsigned 32-bit int instead of a signed one, and gcc follows this
nonsense. thus, to give a conformant environment, we have to follow
(otherwise L""[0] and L'\0' would be 0U rather than 0, but the
application would be unaware due to a mismatched definition for
WCHAR_MIN and WCHAR_MAX, and Bad Things could happen with respect to
signed/unsigned comparisons, promotions, etc.).

fortunately no rules are imposed by the C standard on the relationship
between wchar_t and wint_t, and WEOF has type wint_t, so we can still
make wint_t always-signed and use -1 for WEOF.

this port assumes eabi calling conventions, eabi linux syscall
convention, and presence of the kernel helpers at 0xffff0f?0 needed
for threads support. otherwise it makes very few assumptions, and the
code should work even on armv4 without thumb support, as well as on
systems with thumb interworking. the bits headers declare this a
little endian system, but as far as i can tell the code should work
equally well on big endian.

some small details are probably broken; so far, testing has been
limited to qemu/aboriginal linux.

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.

this slightly cuts down on the degree musl "fights with" gcc, but more
importantly, it fixes a critical bug when gcc inlines a variadic
function and optimizes out the variadic arguments due to noticing that
they were "not used" (by __builtin_va_arg).

we leave the old code in place if __GNUC__ >= 3 is false; it seems
like it might be necessary at least for tinycc support and perhaps if
anyone ever gets around to fixing gcc 2.95.3 enough to make it work..

the basic idea is that the only things in alltypes.h should be types
that either vary from system to system (in practice, not just in
theoretical la-la land - this is the implementation so we choose what
constraints we want to impose on ports) or which are needed by
multiple system headers.

instead of allocating a userspace structure for signal-based timers,
simply use the kernel timer id. we use the fact that thread pointers
will always be zero in the low bit (actually more) to encode integer
timerid values as pointers.

also, this change ensures that the timer_destroy syscall has completed
before the library timer_destroy function returns, in case it matters.

this allows sys/types.h to provide the pthread types, as required by
POSIX. this design also facilitates forcing ABI-compatible sizes in
the arch-specific alltypes.h, while eliminating the need for
developers changing the internals of the pthread types to poke around
with arch-specific headers they may not be able to test.

note that object files using sigset_t (or struct sigaction) need to be
recompiled to work correctly after this fix.

thanks to Peter Mazinger (psm) for pointing many of these issues out
and submitting a patch on which this commit is loosely based