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.
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@
floating-point support, remove default definition of FLOATING_POINT
from the source, and change the compile-time option to
NO_FLOATING_POINT.
- Remove the HEXFLOAT option. It saves an insignificant amount of
space (<0.1% of the size of libc on i386) and complicates vfprintf()
and checkfmt().
after their change from an array of char to an array of enum.
This fixes problems that occurred when using positional arguments in
format strings, particularly with more than STATIC_ARG_TBL_SIZE (8)
of them.
PR: 65841
Submitted by: Steven Smith (mostly)
these are not fully implemented and ifdef'd out, the bugs have
never manifested themselves. Specifically:
- Fix a memory leak in the case where %a follows another
floating-point format.
- Make the %a/%A code behave like %e/%E with respect to
precision.
- It is no longer valid to assume that '-' and '0x' are
mutually exclusive.
- Address other minor issues.
%f and sufficiently short %g specifiers where the precision was
explicitly zero, no '#' flag was specified, and the floating point
argument was > 0 and <= 0.5. While at it, add some comments to better
explain the relevant bits of code.
Noticed by: Christoph Kukulies <kuku@physik.rwth-aachen.de>
be printed.
- Fix %f conversions where the number of significant digits is < expt.
This would be a one-line change were it not for thousands separators.
Noticed by tjr.
- Remove some unnecessary code in the parsing of precision specifiers.
- We used to round long double arguments to double. Now we print
them properly.
- Bugs involving '%F', corner cases of '#' and 'g' format
specifiers, and the '.*' precision specifier have been
fixed.
- Added support for the "'" specifier to print thousands' grouping
characters in a locale-dependent manner.
- Implement the __vfprintf() side of hexadecimal floating point
support. All that is still needed is a routine to convert the
mantissa to hex digits one nibble at a time in the style of ultoa().
Reviewed by: silence on standards@
- __vfprintf()'s 'buf' has never been used for floating point, so
don't define it in terms of (incorrect) constants describing
floating point numbers. The actual size needed depends on
sizeof(uintmax_t) and locale details, so I slightly overestimated.
- We don't need a 308-character buffer to store the string "308".
With long doubles and %a we need more than three characters, though.
dtoa() is buggy. The bug would cause incorrect output to be
generated when format strings such as '%5.0f' were used with
nonzero numbers whose magnitude is less than 1.
Reported by: df(1) by way of periodic(8)
Reviewed by: mike
package, a more recent, generalized set of routines. Among the
changes:
- Declare strtof() and strtold() in stdlib.h.
- Add glue to libc to support these routines for all kinds
of ``long double''.
- Update printf() to reflect the fact that dtoa works slightly
differently now.
As soon as I see that nothing has blown up, I will kill
src/lib/libc/stdlib/strtod.c. Soon printf() will be able
to use the new routines to output long doubles without loss
of precision, but numerous bugs in the existing code must
be addressed first.
Reviewed by: bde (briefly), mike (mentor), obrien
and wide characters. These were already documented in the manual page,
with an entry mentioning that they were not implemented yet. The XSI
%S and %C synoyms have not been added.
In original version grouping was hardcoded. It assumed that thousands
separator should be inserted to separate each 3 numbers. I.e. grouping
string "\003" was assumed for all cases. In correct case (per POSIX)
vfprintf should respect locale defined non-monetary (LC_NUMERIC
category) grouping sequence.
Also simplify thousands_sep handling.
- New length modifiers: hh, j, t, z.
- New flag: '. Note that %'f is not yet implemented.
- Use "inf"/"nan" for efg formats, "INF"/"NAN" for EFG formats.
- Implemented %q in terms of %ll; if "quad_t" is not "long long"
%q will break.
Still to do:
- %C, %S, %lc, %ls (wide character support)
- %'f (thousands in integer portion of %f)
- %a/%A (exact hex representation of floating-point numbers)
Garrett Wollman wrote the first version of the vfprintf.c update;
Mike Barcroft wrote the first version of the printf.3 changes.
Change __dtoa to not free the string it allocated the previous time it was
called. The caller now frees the string after usage if appropiate.
PR: 15070
Reviewed by: deischen
