pcc turned up this bug by calling f->close(f) before fflush(f),
resulting in lost output and error on flush.

with this patch, musl compiles and mostly works with pcc 1.0.0. a few
tests are still failing and i'm uncertain whether they are due to
portability problems in musl, or bugs in pcc, but i suspect the
latter.

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 old versions worked, but conflicted with programs which declared
their own prototypes and generated warnings with some versions of gcc.

Smoothsort is an adaptive variant of heapsort. This version was
written by Valentin Ochs (apo) specifically for inclusion in musl. I
worked with him to get it working in O(1) memory usage even with giant
array element widths, and to optimize it heavily for size and speed.
It's still roughly 4 times as large as the old heap sort
implementation, but roughly 20 times faster given an almost-sorted
array of 1M elements (20 being the base-2 log of 1M), i.e. it really
does reduce O(n log n) to O(n) in the mostly-sorted case. It's still
somewhat slower than glibc's Introsort for random input, but now
considerably faster than glibc when the input is already sorted, or
mostly sorted.

strictly speaking this and a few other ops should be factored into
asm.h or the file should just be renamed to asm.h, but whatever. clean
it up someday.

1. failed match of literal chars from the format string would always
return matching failure rather than input failure at eof, leading to
infinite loops in some programs.

2. unread of eof would wrongly adjust the character counts reported by
%n, yielding an off-by-one error.

this is explicitly allowed by POSIX

some functions that should have been testing whether pthread_self()
had been called and initialized the thread pointer were instead
testing whether pthread_create() had been called and actually made the
program "threaded". while it's unlikely any mismatch would occur in
real-world problems, this could have introduced subtle bugs. now, we
store the address of the main thread's thread descriptor in the libc
structure and use its presence as a flag that the thread register is
initialized. note that after fork, the calling thread (not necessarily
the original main thread) is the new main thread.

the linux documentation for dup2 says it can fail with EBUSY due to a
race condition with open and dup in the kernel. shield applications
(and the rest of libc) from this nonsense by looping until it succeeds

the check against MADV_DONTNEED to because linux MADV_DONTNEED
semantics conflict dangerously with the POSIX semantics

this also de-uglifies the dummy function aliasing a bit.