(let ((i (sb-c::values-type-intersection x y)))
(assert (sb-c::type= i (sb-c::values-type-intersection i x)))
(assert (sb-c::type= i (sb-c::values-type-intersection i y)))))))
+
+370: reader misbehaviour on large-exponent floats
+ (read-from-string "1.0s1000000000000000000000000000000000000000")
+ causes the reader to attempt to create a very large bignum (which it
+ will then attempt to coerce to a rational). While this isn't
+ completely wrong, it is probably not ideal -- checking the floating
+ point control word state and then returning the relevant float
+ (most-positive-short-float or short-float-infinity) or signalling an
+ error immediately would seem to make more sense.
+changes in sbcl-0.8.20 (0.9alpha.0?) relative to sbcl-0.8.18:
+ * fixed some bugs related to Unicode integration:
+ ** portions of multibyte characters at the end of buffers for
+ character-based file input are correctly transferred to the
+ start of the buffer at the next read.
+
changes in sbcl-0.8.19 relative to sbcl-0.8.18:
* new port: SBCL now works in native 64-bit mode on x86-64/Linux
platform. The port supports 61-bit fixnums, large memory spaces
(when (null count)
(simple-stream-perror "couldn't read from ~S" stream err))
(setf (fd-stream-listen stream) nil
- (fd-stream-ibuf-head stream) new-head
+ (fd-stream-ibuf-head stream) 0
(fd-stream-ibuf-tail stream) (+ count new-head))
count)))
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.8.19"
+"0.8.19.1"