previously, write errors neither stopped further output attempts nor
caused the function to return an error to the caller. this could
result in silent loss of output, possibly in the middle of output in
the event of a non-permanent error.

the simplest solution is temporarily clearing the error flag for the
target stream, then suppressing further output when the error flag is
set and checking/restoring it at the end of the operation to determine
the correct return value.

since the wide version of the code internally calls the narrow fprintf
to perform some of its underlying operations, initial clearing of the
error flag is suppressed when performing a narrow vfprintf on a
wide-oriented stream. this is not a problem since the behavior of
narrow operations on wide-oriented streams is undefined.

(cherry picked from commit d42269d7c85308abdbf8cee38b1a1097249eb38b)

in this case there are two conflicting rules in play: that an explicit
precision of zero with the value zero produces no output, and that the
'#' modifier for octal increases the precision sufficiently to yield a
leading zero. ISO C (7.19.6.1 paragraph 6 in C99+TC3) includes a
parenthetical remark to clarify that the precision-increasing behavior
takes precedence, but the corresponding text in POSIX off of which I
based the implementation is missing this remark.

this issue was covered in WG14 DR#151.

(cherry picked from commit b91cdbe2bc8b626aa04dc6e3e84345accf34e4b1)

previously, fgets, fputs, fread, and fwrite completely omitted locking
and access to the FILE object when their arguments yielded a zero
length read or write operation independent of the FILE state. this
optimization was invalid; it wrongly skipped marking the stream as
byte-oriented (a C conformance bug) and exposed observably missing
synchronization (a POSIX conformance bug) where one of these functions
could wrongly complete despite another thread provably holding the
lock.

(cherry picked from commit 6e2bb7acf42589fb7130b039d0623e2ca42503dd)

the C standard requires that "the contents of the array remain
unchanged" in this case.

this patch also changes the behavior on read errors, but in that case
"the array contents are indeterminate", so the application cannot
inspect them anyway.

(cherry picked from commit 402611c3ba3be5b3b0486835d98e22ac7ced2722)

previously we detected this bug in configure and issued advice for a
workaround, but this turned out not to work. since then gcc 4.9.0 has
appeared in several distributions, and now 4.9.1 has been released
without a fix despite this being a wrong code generation bug which is
supposed to be a release-blocker, per gcc policy.

since the scope of the bug seems to affect only data objects (rather
than functions) whose definitions are overridable, and there are only
a very small number of these in musl, I am just changing them from
const to volatile for the time being. simply removing the const would
be sufficient to make gcc 4.9.1 work (the non-const case was
inadvertently fixed as part of another change in gcc), and this would
also be sufficient with 4.9.0 if we forced -O0 on the affected files
or on the whole build. however it's cleaner to just remove all the
broken compiler detection and use volatile, which will ensure that
they are never constant-folded. the quality of a non-broken compiler's
output should not be affected except for the fact that these objects
are no longer const and thus possibly add a few bytes to data/bss.

this change can be reconsidered and possibly reverted at some point in
the future when the broken gcc versions are no longer relevant.

(cherry picked from commit a6adb2bcd8145353943377d6119c1d7a4242bae1)

the purpose of this logic is to avoid linking __stdio_exit unless any
stdio reads (which might require repositioning the file offset at exit
time) or writes (which might require flushing at exit time) could have
been performed.

previously, exit called two wrapper functions for __stdio_exit named
__flush_on_exit and __seek_on_exit. both of these functions actually
performed both tasks (seek and flushing) by calling the underlying
__stdio_exit. in order to avoid doing this twice, an overridable data
object __towrite_used was used to cause __seek_on_exit to act as a nop
when __towrite was linked.

now, exit only makes one call, directly to __stdio_exit. this is
satisfiable by a weak dummy definition in exit.c, but the real
definition is pulled in by either __toread.c or __towrite.c through
their referencing a symbol which is defined only in __stdio_exit.c.

(cherry picked from commit c463e11eda8326aacee2ac1d516954a9574a2dcd)

in some cases, these functions internally call a byte-based input or
output function before calling getwc/putwc, so they cannot rely on the
latter to set the orientation.

(cherry picked from commit 984c25b74da085c6ae6b44a87bbd5f8afc9be331)

when the orientation of the stream was already set, fwide was
incorrectly returning its argument (the requested orientation) rather
than the actual orientation of the stream.

(cherry picked from commit ebd8142a6ae19db1a5440d11c01afc7529eae0cd)

the subsequent rounding code assumes the end pointer (z) accurately
reflects the end of significance in the decimal expansion, but for
certain large integers, spurious trailing zero slots were left behind
when applying the binary exponent.

issue reported by Morten Welinder; the analysis of the cause was
performed by nsz, who also proposed this change.

(cherry picked from commit e94d0692864ecf9522fd6a97610a47a2f718d3de)

the code to strip trailing zeros was only looking in the last slot for
up to 9 zeros, assuming that the rounding code had already removed
fully-zero slots from the end. however, this ignored cases where the
rounding code did not run at all, which occur when the value being
printed is exactly representable in the requested precision.

the simplest solution is to move the code that strips trailing zero
slots to run unconditionally, immediately after rounding, rather than
as the last step of rounding.

(cherry picked from commit 89740868c9f1c84b8ee528468d12df1fa72cd392)