Re: One bug in CMUCL (version 15a?)

[Paul_Gleichauf@B.GP.CS.CMU.EDU]

Jonathan,
	I have examined the format behavior that you have reported
as a bug:

> * (format nil "~16,9,2E" -9.9999999999d0)

> "-10.000000000e+00"
> * (length *)

> 17

As you have noted the rounding up of the 10 9's to the right of
the decimal point causes 9 0's in the returned printed
representation.  There are 9 places reserved in the format 
directive. Pus one for the decimal point. There are two places 
reserved for the the digits of the exponent, one for its sign,
another for the E. That's 14 so far. Now the leading minus sign
requires 1 place and the rounded 10 two more. That is 17 required
by the format directive.  If you use the positive version :

* (format nil "~16,9,2E" 9.9999999999d0)
"10.000000000d+00"
* (length *)
16
*  
You can also trigger the behavior you have reported by increasing
the exponent to three digits.

I will refer you to Steele CLtL2 p.590.

"If it is impossible to print the value in the required format in a
field of width w, possibly because k is too large or too small or
because the exponent cannot be printed in e character positions,
then one of two actions is taken. If the parameter overflowchar is
specified, then w copies of that parameter are printed instead of
the scaled value of arg. If the overflow character is omitted, then
the scaled value is printed using more than w characters, as many
more as may be needed; if the problem is that d is too small for the
specified k or that e is too small, then a larger value is used for
d or e as may be needed."

Try the overflow character in the format specification.  It is
triggered.  Hence I have concluded that the behavior is correct.
Let me know if there are further problems because of this
interpretation of the specification.

	In general bug reports should be sent to the address on the
banner when you start up CMU CL, i.e. cmucl-bugs@cs.cmu.edu and not
through our slisp-group internal mailing list.

						Paul