structure and call stdio functions. In 5.X this was broken when FILE
locking was introduced into libc.
This change makes most (relevant) stdio functions work again when the
_extra file in FILE isn't initialised (and can't be without a libc
function to do it since the __sFILEX structure is private to libc).
- Update and improve the documentation for %[aA]
o Like %[eE], %[aA] may round the result if a precision is specified.
o Grammar police: Fix a split infinitive.
o The FreeBSD implementation does better than the minimum required
by C99 (literal translation of the mantissa). The digit before
the hexadecimal-point is never 0 unless the number itself is 0.
o Clarify that the exponent field represents a decimal exponent of 2.
o Discuss the fact that multiple valid representations are possible.
o Remove the entry in the BUGS section claiming that %[aA] is not
implemented.
- Remove the entry in the BUGS section claiming that the ' flag for
printing thousands separators is unimplemented for floating-point.
- Remove the entry in the BUGS section claiming that the L modifier
reduces the precision to "double" before conversion.
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.
string files (__SSTR flag set). This is necessary because __sputc()
does not respect the __SALC flag, and crashes trying to flush the buffer
instead of resizing it.
PR: 59167
mbstate_t object that they ignore. The zeroing is fairly expensive, and it
will never be necessary in these functions; when we support state-dependent
encodings, we will pass in a pointer to the file's mbstate_t object, and
only zero it at the time the file gets opened.
by sizeof(wchar_t) to get the number of wide characters it contains.
Remove the !hardway micro-optimisation from the CT_INT case to avoid
having to fix it for wide characters.
is made an array of two, to explicitly avoid stack corruption due to
null-terminating (which is doesn't actually happen due to stack alignment
padding).
Submitted by: Ed Moy <emoy@apple.com>
Obtained from: Apple Computer, Inc.
[+|-]Inf, [+|-]NaN, nan(...), and hexidecimal FP constants.
While here, add %a and %A, which are aliases for %e, and
add support for long doubles.
Reviewed by: standards@
%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
Only warnings that could be fixed without changing the generated object
code and without restructuring the source code have been handled.
Reviewed by: /sbin/md5
a NULL filename argument allows a stream's mode to be changed. At the
moment it just recycles the old file descriptor instead of storing the
filename somewhere and using that to reopen the file, as the standard
seems to require. Strictly conforming C99 applications probably can't
tell the difference but POSIX ones can.
PR: 46791
putchar_unlocked(), putc_unlocked(), feof_unlocked(), ferror_unlocked(),
clearerr_unlocked(), and fileno_unlocked(). The first four are required
by POSIX. The rest are provided for consistency.
to be static for 5.0. I may remove this for 5.1 or 5.2. No more
binaries or libarires will be generated with __sF starting as of
yesterday. Originally the plan had been to eliminate this for 5.0,
but we didn't get the __std{in,out,err}p changes merged into -stable
until yesterday (rather than in September 2001 like it should have
been). Given that didn't happen on time, we can't do the other part
of the scheme now.
# Please do not change this without talking to me first.
maximum number of bytes that may be stored in the array, not the maximum
number of wide characters to read. The wording of the standard unfortunately
does not make this clear.
