about summary refs log tree commit diff
path: root/src/stdio/vfprintf.c
Commit message (Collapse)AuthorAgeFilesLines
* byte-based printf family: emit a nul byte for %lc with argument zeroRich Felker2023-11-061-0/+2
| | | | | | | | this is contrary to the spec as written, which requires %lc to behave as if it were %ls on a 2-wchar_t buffer containing the argument and zero. however, apparently no other implementations conform to the spec as written, and in response to Austin Group issue #1647, WG14 chose to align with existing practice and have %lc produce output for this case.
* printf core: fix gratuitous integer formatting buffer sizeRich Felker2023-06-121-1/+1
| | | | | | | | | | | the extra terms 3 and LDBL_MANT_DIG/4 are remnants of a proto-musl implementation of printf where the sign/prefix and floating point conversions were performed naively into this buffer. having them there obscures the actual intended buffer size (sufficient to hold between 2 and 3 octal digits per byte, rounded up to 3 for simplicity) and interferes with upcoming work to add C2x binary formats which would otherwise be stuck having to explain a similar fix to buffer size as part of an unrelated change.
* all printf variants: fix argument type handling for %c and %lcRich Felker2023-06-121-2/+2
| | | | | | | | | | | | | | | | %c takes an argument of type int, not char, and %lc/%C takes an argument of type wint_t (unsigned), not int. for most cases, this makes no practical difference, but since wide printf variants convert narrow %c format specifiers via btowc, interpreting the promoted-to-int unsigned char value passed in as a (signed, on most archs) char causes 255 to get collapsed to EOF and interpreted as such by btowc. this is only relevant in the byte-based C locale, so prior to commit f22a9edaf8a6f2ca1d314d18b3785558279a5c03, there was no observable distinction in behavior. for UTF-8, all bytes which might be negative when interpreted as char are encoding errors when used with %c/btowc.
* in printf, use ferror macro rather than directly inspecting flags bitRich Felker2023-03-211-2/+2
| | | | | this is purely aesthetic and should not affect code generation or functionality.
* remove wide printf dependency on ugly hack in vfprintfRich Felker2023-03-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* fix (normal, narrow) printf erroneously processing %n after output errorsRich Felker2023-03-211-0/+3
| | | | | | | | | | | | | | | 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.
* prevent invalid reads of nl_arg in printf_coreMarkus Wichmann2022-12-141-6/+8
| | | | | | | | | | | | | | 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.
* reduce spurious inclusion of libc.hRich Felker2018-09-121-0/+1
| | | | | | | | | | | | | | | | | | | | | libc.h was intended to be a header for access to global libc state and related interfaces, but ended up included all over the place because it was the way to get the weak_alias macro. most of the inclusions removed here are places where weak_alias was needed. a few were recently introduced for hidden. some go all the way back to when libc.h defined CANCELPT_BEGIN and _END, and all (wrongly implemented) cancellation points had to include it. remaining spurious users are mostly callers of the LOCK/UNLOCK macros and files that use the LFS64 macro to define the awful *64 aliases. in a few places, new inclusion of libc.h is added because several internal headers no longer implicitly include libc.h. declarations for __lockfile and __unlockfile are moved from libc.h to stdio_impl.h so that the latter does not need libc.h. putting them in libc.h made no sense at all, since the macros in stdio_impl.h are needed to use them correctly anyway.
* make vfprintf set stream orientation even for zero-length outputRich Felker2018-08-291-1/+2
| | | | | | | if no output is produced, no underlying fwrite will ever be called, but byte-oriented printf functions are still required to set the orientation of the stream to byte-oriented. call __towrite explicitly if the FILE is not already in write mode.
* re-fix vfprintf temporary buffer logicRich Felker2018-08-291-2/+2
| | | | | | | | | | | | commit b5a8b28915aad17b6f49ccacd6d3fef3890844d1 setup the write buffer bound pointers for the temporary buffer manually to fix a buffer overflow issue, but in doing so, caused vfprintf on unbuffered files never to call __towrite, thereby failing to set the stream orientation to byte-oriented, failing to clear any prior read mode, and failing to produce an error when the stream is not writable. revert the inline setup of the bounds pointers and instead zero them, so that the underlying fwrite code will call __towrite to set them up.
* fix printf precision specifier for hex floats on non-ld80 archsRich Felker2018-08-231-0/+1
| | | | | | | | | the code to perform rounding to the desired precision wrongly assumed the long double mantissa was an integral number of nibbles (hex digits) in length. this is true for 80-bit extended precision (64-bit mantissa) but not for double (53) or quad (113). scale the rounding value by 1<<(LDBL_MANT_DIG%4) to compensate.
* fix printf alt-form octal with value 0 and no explicit precisionRich Felker2018-01-101-2/+2
| | | | | | | | | | | | | | | | | | commit 78897b0dc00b7cd5c29af5e0b7eebf2396d8dce0 wrongly simplified Dmitry Levin's original submitted patch fixing alt-form octal with the zero flag and field width present, omitting the special case where the value is zero. as a result, printf("%#o",0) wrongly prints "00" rather than "0". the logic prior to this commit was actually better, in that it was aligned with how the alt-form flag (#) for printf is specified ("it shall increase the precision"). at the time there was no good way to avoid the zero flag issue with the old logic, but commit 167dfe9672c116b315e72e57a55c7769f180dffa added tracking of whether an explicit precision was provided. revert commit 78897b0dc00b7cd5c29af5e0b7eebf2396d8dce0 and switch to using the explicit precision indicator for suppressing the zero flag.
* remove ineffective compiler assist from printfAlexander Monakov2017-07-041-2/+0
| | | | | | The switch statement has no 'default:' case and the function ends immediately following the switch, so the extra comparison did not communicate any extra information to the compiler.
* remove va_arg hacks in printf core with undefined behaviorRich Felker2017-04-221-26/+1
| | | | | | | | | | | | | | the code being removed was written to optimize for size assuming the compiler cannot collapse code paths for different types with the same underlying representation. modern compilers sometimes succeed in making this optimization themselves, but either way it's a small size difference and not worth the source-level complexity or the UB involved in this hack. some incorrect use of va_arg still remains, particularly use of void * where the actual argument has a different pointer type. fixing this requires some actual code additions, rather than just removing cruft, so I'm leaving it to be done later as a separate commit.
* fix float formatting of some exact halfway casesSzabolcs Nagy2016-10-201-1/+2
| | | | | | | | in nearest rounding mode exact halfway cases were not following the round to even rule if the rounding happened at a base 1000000000 digit boundary of the internal representation and the previous digit was odd. e.g. printf("%.0f", 1.5) printed 1 instead of 2.
* fix integer overflows and uncaught EOVERFLOW in printf coreRich Felker2016-10-201-22/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | this patch fixes a large number of missed internal signed-overflow checks and errors in determining when the return value (output length) would exceed INT_MAX, which should result in EOVERFLOW. some of the issues fixed were reported by Alexander Cherepanov; others were found in subsequent review of the code. aside from the signed overflows being undefined behavior, the following specific bugs were found to exist in practice: - overflows computing length of floating point formats with huge explicit precisions, integer formats with prefix characters and huge explicit precisions, or string arguments or format strings longer than INT_MAX, resulted in wrong return value and wrong %n results. - literal width and precision values outside the range of int were misinterpreted, yielding wrong behavior in at least one well-defined case: string formats with precision greater than INT_MAX were sometimes truncated. - in cases where EOVERFLOW is produced, incorrect values could be written for %n specifiers past the point of exceeding INT_MAX. in addition to fixing these bugs, we now stop producing output immediately when output length would exceed INT_MAX, rather than continuing and returning an error only at the end.
* fix integer overflow in float printf needed-precision computationRich Felker2016-10-191-1/+1
| | | | | | | | | | | | | | if the requested precision is close to INT_MAX, adding LDBL_MANT_DIG/3+8 overflows. in practice the resulting undefined behavior manifests as a large negative result, which is then used to compute the new end pointer (z) with a wildly out-of-bounds value (more overflow, more undefined behavior). the end result is at least incorrect output and character count (return value); worse things do not seem to happen, but detailed analysis has not been done. this patch fixes the overflow by performing the intermediate computation as unsigned; after division by 9, the final result necessarily fits in int.
* fix printf regression with alt-form octal, zero flag, and field widthRich Felker2016-09-161-1/+1
| | | | | | | | | | commit b91cdbe2bc8b626aa04dc6e3e84345accf34e4b1, in fixing another issue, changed the logic for how alt-form octal adds the leading zero to adjust the precision rather than using a prefix character. this wrongly suppressed the zero flag by mimicing an explicit precision given by the format string. switch back to using a prefix character. based on bug report and patch by Dmitry V. Levin, but simplified.
* don't suppress sign output for NANs in printfRich Felker2014-12-181-1/+1
| | | | | | | | | formally, it seems a sign is only required when the '+' modifier appears in the format specifier, in which case either '+' or '-' must be present in the output. but the specification is written such that an optional negative sign is part of the output format anyway, and the simplest approach to fixing the problem is removing the code that was suppressing the sign.
* correctly handle write errors encountered by printf-family functionsRich Felker2014-12-171-1/+6
| | | | | | | | | | | | | | | | | | 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.
* fix behavior of printf with alt-form octal, zero precision, zero valueRich Felker2014-11-151-1/+1
| | | | | | | | | | | | 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.
* use cleaner code for handling float rounding in vfprintfSzabolcs Nagy2014-05-301-3/+1
| | | | | | | CONCAT(0x1p,LDBL_MANT_DIG) is not safe outside of libc, use 2/LDBL_EPSILON instead. fix was proposed by Morten Welinder.
* fix printf rounding with %g for some corner case midpointsRich Felker2014-04-071-1/+1
| | | | | | | | | | 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.
* fix failure of printf %g to strip trailing zeros in some casesRich Felker2014-04-071-1/+1
| | | | | | | | | | | | 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.
* fix carry into uninitialized slots during printf floating point roundingRich Felker2014-04-071-1/+1
| | | | | | | | | | | | | in cases where rounding caused a carry, the slot into which the carry was taking place was unconditionally treated as valid, despite the possibility that it could be a new slot prior to the beginning of the existing non-rounded number. in theory this could lead to unbounded runaway carry, but in order for that to happen, the whole uninitialized buffer would need to have been pre-filled with 32-bit integer values greater than or equal to 999999999. patch based on proposed fix by Morten Welinder, who also discovered and reported the bug.
* fix incorrect rounding in printf floating point corner casesRich Felker2014-03-091-2/+2
| | | | | | | | | | | | | | the printf floating point formatting code contains an optimization to avoid computing digits that will be thrown away by rounding at the specified (or default) precision. while it was correctly retaining all places up to the last decimal place to be printed, it was not retaining enough precision to see the next nonzero decimal place in all cases. this could cause incorrect rounding down in round-to-even (default) rounding mode, for example, when printing 0.5+DBL_EPSILON with "%.0f". in the fix, LDBL_MANT_DIG/3 is a lazy (non-sharp) upper bound on the number of zeros between any two nonzero decimal digits.
* fix buffer overflow in printf formatting of denormals with low bit setRich Felker2014-03-091-1/+2
| | | | | | | | | | | empirically the overflow was an off-by-one, and it did not seem to be overwriting meaningful data. rather than simply increasing the buffer size by one, however, I have attempted to make the size obviously correct in terms of bounds on the number of iterations for the loops that fill the buffer. this still results in no more than a negligible size increase of the buffer on the stack (6-7 32-bit slots) and is a "safer" fix unless/until somebody wants to do the proof that a smaller buffer would suffice.
* minor vfprintf and vfwprintf changes to please static code analyzersSzabolcs Nagy2013-10-071-2/+5
| | | | add missing va_end and remove some unnecessary code.
* protect against long double type mismatches (mainly powerpc for now)Rich Felker2013-08-021-0/+7
| | | | | | check in configure to be polite (failing early if we're going to fail) and in vfprintf.c since that is the point at which a mismatching type would be extremely dangerous.
* clean up stdio_impl.hRich Felker2012-11-081-0/+9
| | | | | | | | | | | this header evolved to facilitate the extremely lazy practice of omitting explicit includes of the necessary headers in individual stdio source files; not only was this sloppy, but it also increased build time. now, stdio_impl.h is only including the headers it needs for its own use; any further headers needed by source files are included directly where needed.
* avoid raising spurious division-by-zero exception in printfRich Felker2012-10-181-1/+1
|
* use restrict everywhere it's required by c99 and/or posix 2008Rich Felker2012-09-061-1/+1
| | | | | | | | to deal with the fact that the public headers may be used with pre-c99 compilers, __restrict is used in place of restrict, and defined appropriately for any supported compiler. we also avoid the form [restrict] since older versions of gcc rejected it due to a bug in the original c99 standard, and instead use the form *restrict.
* minor but worthwhile optimization in printf: avoid expensive strspnRich Felker2012-08-101-4/+2
| | | | | | the strspn call was made for every format specifier and end-of-string, even though the expected return value was 1-2 for normal usage. replace with simple loop.
* fix another oob pointer arithmetic issue in printf floating pointRich Felker2012-06-201-1/+1
| | | | | | this one could never cause any problems unless the compiler/machine goes to extra trouble to break oob pointer arithmetic, but it's best to fix it anyway.
* fix pointer overflow bug in floating point printfRich Felker2012-06-191-3/+3
| | | | | | | | | | | | | | | | | | | | | large precision values could cause out-of-bounds pointer arithmetic in computing the precision cutoff (used to avoid expensive long-precision arithmetic when the result will be discarded). per the C standard, this is undefined behavior. one would expect that it works anyway, and in fact it did in most real-world cases, but it was randomly (depending on aslr) crashing in i386 binaries running on x86_64 kernels. this is because linux puts the userspace stack near 4GB (instead of near 3GB) when the kernel is 64-bit, leading to the out-of-bounds pointer arithmetic overflowing past the end of address space and giving a very low pointer value, which then compared lower than a pointer it should have been higher than. the new code rearranges the arithmetic so that no overflow can occur. while this bug could crash printf with memory corruption, it's unlikely to have security impact in real-world applications since the ability to provide an extremely large field precision value under attacker-control is required to trigger the bug.
* fix %ls breakage in last printf fixRich Felker2012-06-081-2/+2
| | | | signedness issue kept %ls with no precision from working at all
* fix printf %ls with precision limit over-read issueRich Felker2012-06-081-2/+2
| | | | | | | printf was not printing too many characters, but it was reading one too many wchar_t elements from the input. this could lead to crashes if running off the page, or spurious failure if the conversion of the extra wchar_t resulted in EILSEQ.
* fix buffer overflow in vfprintf on long writes to unbuffered filesRich Felker2012-04-171-1/+2
| | | | | | | | | | | | | | | | | | vfprintf temporarily swaps in a local buffer (for the duration of the operation) when the target stream is unbuffered; this both simplifies the implementation of functions like dprintf (they don't need their own buffers) and eliminates the pathologically bad performance of writing the formatted output with one or more write syscalls per formatting field. in cases like dprintf where we are dealing with a virgin FILE structure, everything worked correctly. however for long-lived files (like stderr), it's possible that the buffer bounds were already set for the internal zero-size buffer. on the next write, __stdio_write would pick up and use the new buffer provided by vfprintf, but the bound (wend) field was still pointing at the internal zero-size buffer's end. this in turn allowed unbounded writes to the temporary buffer.
* fix %lf, etc. with printfRich Felker2012-04-161-0/+2
| | | | | | the l prefix is redundant/no-op with printf, since default promotions always promote floats to double; however, it is valid, and printf was wrongly rejecting it.
* don't crash on null strings in printfRich Felker2011-09-281-1/+1
| | | | passing null pointer for %s is UB but lots of broken programs do it anyway
* printf: "if a precision is specified, the '0' flag shall be ignored."Rich Felker2011-07-041-1/+1
|
* zero precision with zero value should not inhibit prefix/width printingRich Felker2011-07-041-1/+4
|
* printf("%#x",0) should print 0 not 0x0Rich Felker2011-07-041-1/+1
|
* fix the last known rounding bug in floating point printingRich Felker2011-05-111-3/+4
| | | | | | | | | the observed symptom was that the code was incorrectly rounding up 1.0625 to 1.063 despite the rounding mode being round-to-nearest with ties broken by rounding to even last place. however, the code was just not right in many respects, and i'm surprised it worked as well as it did. this time i tested the values that end up in the variables round, small, and the expression round+small, and all look good.
* fix printf("%.9g", 1.1) and similar not dropping trailing zerosRich Felker2011-04-121-1/+3
|
* fix overflow in printf %N$ argument handlingRich Felker2011-04-051-2/+2
|
* fix various floating point rounding and formatting errors in *printfRich Felker2011-04-051-17/+25
|
* use a local temp buffer for unbuffered streams in vfprintfRich Felker2011-04-041-0/+13
| | | | | | | | | this change makes it so most calls to fprintf(stderr, ...) will result in a single writev syscall, as opposed to roughly 2*N syscalls (and possibly more) where N is the number of format specifiers. in principle we could use a much larger buffer, but it's best not to increase the stack requirements too much. most messages are under 80 chars.
* major stdio overhaul, using readv/writev, plus other changesRich Felker2011-03-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the biggest change in this commit is that stdio now uses readv to fill the caller's buffer and the FILE buffer with a single syscall, and likewise writev to flush the FILE buffer and write out the caller's buffer in a single syscall. making this change required fundamental architectural changes to stdio, so i also made a number of other improvements in the process: - the implementation no longer assumes that further io will fail following errors, and no longer blocks io when the error flag is set (though the latter could easily be changed back if desired) - unbuffered mode is no longer implemented as a one-byte buffer. as a consequence, scanf unreading has to use ungetc, to the unget buffer has been enlarged to hold at least 2 wide characters. - the FILE structure has been rearranged to maintain the locations of the fields that might be used in glibc getc/putc type macros, while shrinking the structure to save some space. - error cases for fflush, fseek, etc. should be more correct. - library-internal macros are used for getc_unlocked and putc_unlocked now, eliminating some ugly code duplication. __uflow and __overflow are no longer used anywhere but these macros. switch to read or write mode is also separated so the code can be better shared, e.g. with ungetc. - lots of other small things.
* fix all implicit conversion between signed/unsigned pointersRich Felker2011-03-251-1/+1
| | | | | | | sadly the C language does not specify any such implicit conversion, so this is not a matter of just fixing warnings (as gcc treats it) but actual errors. i would like to revisit a number of these changes and possibly revise the types used to reduce the number of casts required.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-01 17:12:58 +0000