The nl_type and nl_arg arrays defined in vfwprintf may be accessed with an index up to and including NL_ARGMAX, but they are only of size NL_ARGMAX, meaning they may be written to or read from 1 element too far.
the buffer-flush function did not account for mbtowc returning 0 rather than 1 when converting the nul character. this prevented advancing past it, instead repeatedly converting it into the output wide character string until the max output length was exhausted.
this is purely aesthetic and should not affect code generation or functionality.
commit d42269d7c85308abdbf8cee38b1a1097249eb38b appropriated the stream error flag temporarily to let the printf family of functions suppress further output attempts after encountering a write error. since the wide printf code relies on (narrow) vfprintf to print padding and numeric conversions, a hack was put in vfprintf not to clear the initial error status unless the stream is narrow oriented. this was okay, because calling vfprintf on a wide-oriented stream (outside of internal use by the implementation) produces undefined behavior. however, it was highly non-obvious to anyone reading the wide printf code, where the calls to fprintf without first checking for error status appeared erroneous. this patch removes all direct use of fprintf from the wide printf core, except in the numeric conversions case where it was already checked before starting processing of the directive that the error status is not set. the other calls, which were performing padding, are replaced by a new pad() helper function, which performs the check and abstracts out the mechanism of writing the padding. direct use of the error flag is also replaced by ferror, which is defined as a macro in stdio_impl.h, expanding directly to the flag check with no call or locking overhead.
unlike with wide printf variants, encoding errors are not a vector by which this bug is reachable, and the out() helper function already ensured that no further output could be written after an output error, transient or otherwise. however, the %n specifier could still be processed after an error, yielding a side effect that wrongly implied output had succeeded. due to buffering effects, it's still possible for %n to show output as having "succeeded", but for it never to appear on the underlying file due to an error at flush time. this change, however, ensures that processing of %n does not conflict with any error which has already been seen.
this fixes a broader bug for which a special case was reported by Bruno Haible, in the form of %n getting processed (and reporting the number of wide characters which would have been written, but weren't) after an encoding error (EILSEQ). in addition to the %n case, some but not all of the format specifiers continued to attempt output after an error. in particular, %c, %lc, and %s all used fputwc directly without any check for error status. as long as the error condition was permanent rather than transient, these write attempts had no visible side effects, but in theory it could be visible, for example with EAGAIN/EWOULDBLOCK or ENOSPC, if the condition precluding output came to an end. this could produce output with missing non-final data, rather than just truncated output, albeit with the function still returning -1 as expected to report an error. to fix this, a check is added to stop processing of any new directive (including %n) if the stream is already in error state, and direct use of fputwc is replaced with calls to the out() helper function, which checks for error status. note that fprintf is also used directly without checking error status, but due to how commit d42269d7c85308abdbf8cee38b1a1097249eb38b previously attempted to solve the issue of output after error, the call to fprintf does not attempt to write anything when the wide-oriented stream is already in error state. this is non-obvious, and is quite a hack, so it should be changed, but I've left it alone for now to make the bug fix commit itself as non-invasive as possible.
since the code path for %c was already doing it right, and the logic is identical, condense them into a single case.
printf_core() runs twice, and during its first run, nl_arg is uninitialized and must not be read. It gets initialized at the end of the first run. Conversely, nl_type does not need to be set during the second run, as its useful life has ended at that point, since the only time it is read is during that exact same initialization. Therefore we can simply alternate the assignments. p and w do still need to get values assigned to them, since at least one line in the same if-statement depends on that, but they can be dummy values. arg does not need to be assigned, since in the first run, we encounter a continue statement before using the argument.
performing n-- is not a safe operation for arbitrary signed input n. only perform the decrement in the code path where the initial n is greater than 1, and adjust the condition in the n<=1 code path to compensate for it not having been decremented.
originally the namespace-infringing "large file support" interfaces were included as part of glibc-ABI-compat, with the intent that they not be used for linking, since our off_t is and always has been unconditionally 64-bit and since we usually do not aim to support nonstandard interfaces when there is an equivalent standard interface. unfortunately, having the symbols present and available for linking caused configure scripts to detect them and attempt to use them without declarations, producing all the expected ill effects that entails. as a result, commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c was made to prevent this, using macros to redirect the LFS64 names to the standard names, conditional on _GNU_SOURCE or _LARGEFILE64_SOURCE. however, this has turned out to be a source of further problems, especially since g++ defines _GNU_SOURCE by default. in particular, the presence of these names as macros breaks a lot of valid code. this commit removes all the LFS64 symbols and replaces them with a mechanism in the dynamic linker symbol lookup failure path to retry with the spurious "64" removed from the symbol name. in the future, if/when the rest of glibc-ABI-compat is moved out of libc, this can be removed.