the precision; ANSI X3J11 is not crystal clear but certainly says
that the precision specifies the number of /digits/, and signs
and "0x" aren't really digits.
NetBSD already has a similar patch.
resides in read-only memory is going to cause the program to core dump,
and this is commmon with older pre-ANSI C programs.
(I've scratched my head over this one at 3 in the morning before
while trying to port some ancient program)
Suggested by: Gary Kline <kline@tera.com>
commit by bde.
Fix bugs in floating point formatting. The 4.4lite version is similar
to revision 1.3 in old-cvs and is missing all of jtc's fixes in revision
1.4 in old-cvs. Revision 1.2 in ncvs fixed one of the old bugs but
introduced at least one new one (for %.0e).
old-cvs log:
revision 1.4
date: 1993/11/04 19:38:22; author: jtc; state: Exp; lines: +33 -20
My work from NetBSD to make printf() & friends ANSI C compliant.
Fixes several bugs in floating point formatting:
1. Trailing zeros were being stripped with %e format.
2. %g/%G formats incorrect.
3. Lots of other nits.
From: Chris Torek <torek@bsdi.com>
Here is a semi-official patch (apply to /usr/src/lib/libc/stdio/fseek.c,
rebuild libc, install). The current code fails when the seek:
- is optimized, and
- is to just past the end of the block currently in the buffer, and
- is followed by another seek with no intervening read operation, and
- the destination of subsequent seek is within the block left in the
buffer (seeking to the beginning of a block does not force a read,
so the buffer still contains the previous block)
so it is indeed rather obscure.
I may have a different `final' fix, as this one `loses' the buffer
contents on a seek that goes just past the end of the current block.
[Footnote: seeks are optimized only on read-only opens of regular
files that are buffered by the file's optimal I/O size. This is
what you get with fopen(path, "r") and no call to setvbuf().]
Obtained from: [ BSDI mailing list ]
