FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F7.3.0_cvs 2010-03-21T01:30:13Z 2010-03-21T01:30:13Z Ken Smith kensmith@FreeBSD.org 2010-03-21T01:30:13Z urn:sha1:9c4d1c1956ecb0a222fb2f4579c320391fb67f06 Approved by: re (implicit) This commit was manufactured to restore the state of the 7.3-RELEASE image. 2009-03-14T18:19:50Z David Schultz das@FreeBSD.org 2009-03-14T18:19:50Z urn:sha1:b046f4c0c76df7520dfe09e23395dc8352e5b7df Make sure %zd treats negative arguments properly on 32-bit platforms. PR: 131880 2007-05-08T03:08:28Z David Schultz das@FreeBSD.org 2007-05-08T03:08:28Z urn:sha1:970a466c40b11ffe2fc545e6b94e75f8a1207cf6 even if the programmer asks for zero padding. 2007-01-09T00:28:16Z Warner Losh imp@FreeBSD.org 2007-01-09T00:28:16Z urn:sha1:c879ae3536e6d92b8d96c8965c5b05fcb9541520 clause. # If I've done so improperly on a file, please let me know. 2007-01-03T04:57:58Z David Schultz das@FreeBSD.org 2007-01-03T04:57:58Z urn:sha1:ac9913a74998a19e87540647ab832cf5a18229e0 PR: 90333 2006-09-21T14:40:20Z Alexander Kabaev kan@FreeBSD.org 2006-09-21T14:40:20Z urn:sha1:500b77c7edec133f2f2bf2c4948b447b6338878b 2006-04-01T19:06:54Z Poul-Henning Kamp phk@FreeBSD.org 2006-04-01T19:06:54Z urn:sha1:75239a017f0653feb41a3546cd643c356c56a5df 2005-12-16T18:56:39Z Poul-Henning Kamp phk@FreeBSD.org 2005-12-16T18:56:39Z urn:sha1:75067f4f702154e49d475982591d9dcffa155afe on probationary terms: it may go away again if it transpires it is a bad idea. This extensible printf version will only be used if either environment variable USE_XPRINTF is defined or one of the extension functions are called. or the global variable __use_xprintf is set greater than zero. In all other cases our traditional printf implementation will be used. The extensible version is slower than the default printf, mostly because less opportunity for combining I/O operation exists when faced with extensions. The default printf on the other hand is a bad case of spaghetti code. The extension API has a GLIBC compatible part and a FreeBSD version of same. The FreeBSD version exists because the GLIBC version may run afoul of our FILE * locking in multithreaded programs and it even further eliminate the opportunities for combining I/O operations. Include three demo extensions which can be enabled if desired: time (%T), hexdump (%H) and strvis (%V). %T can format time_t (%T), struct timeval (%lT) and struct timespec (%llT) in one of two human readable duration formats: "%.3llT" -> "20349.245" "%#.3llT" -> "5h39m9.245" %H will hexdump a sequence of bytes and takes a pointer and a length argument. The width specifies number of bytes per line. "%4H" -> "65 72 20 65" "%+4H" -> "0000 65 72 20 65" "%#4H" -> "65 72 20 65 |er e|" "%+#4H" -> "0000 65 72 20 65 |er e|" %V will dump a string in strvis format. "%V" -> "Hello\tWor\377ld" (C-style) "%0V" -> "Hello\011Wor\377ld" (octal) "%+V" -> "Hello%09Wor%FFld" (http-style) Tests, comments, bugreports etc are most welcome. 2005-12-13T13:23:27Z Poul-Henning Kamp phk@FreeBSD.org 2005-12-13T13:23:27Z urn:sha1:b384108ed62a9fb4f8a97eab187098aa77da4b8c For some denormalized long double values, a bug in __hldtoa() (called from *printf()'s %A format) results in a base 16 digit being rounded up from 0xf to 0x10. When this digit is subsequently converted to string format, an index of 10 reaches past the end of the uppper-case hex/char array, picking up whatever the code segment happen to contain at that address. This mostly seem to be some character from the upper half of the byte range. When using the %a format instead of %A, the first character past the end of the lowercase hex/char table happens to be index 0 in the uppercase hex/char table hextable and therefore the string representation features a '0', which is supposedly correct. This leads me to belive that the proper fix _may_ be as simple as masking all but the lower four bits off after incrementing a hex-digit in libc/gdtoa/_hdtoa.c:roundup(). I worry however that the upper bit in 0x10 indicates a carry not carried. Until das@ or bde@ finds time to visit this issue, extend the hexdigit arrays with a 17th index containing '?' so that we get a invalid but consistent and printable output in both %a and %A formats whenever this bug strikes. This unmasks the bug in the %a format therefore solving the real issue may both become easier and more urgent. Possibly related to: PR 85080 With help by: bde@ 2005-07-24T12:12:44Z Tim J. Robbins tjr@FreeBSD.org 2005-07-24T12:12:44Z urn:sha1:d48c77b5342db9071af72292716f97b2dee79f9a - use wcsrtombs() instead of a wcrtomb() loop where possible. - avoid wcrtomb() loop when output precision is small.