Update of /cvsroot/sbcl/sbcl/src/code
In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv32534/src/code
220.127.116.11: make the utf-8 external format more robust
Detect all malformed sequences, including attempts to decode or encode
Unicode surrogate codepoints (disallowed by the Unicode definition of
UTF-8). Some error tests change behaviour, and some (unexported)
condition classes are not triggered under the same circumstances any
Also, handle null-termination on a successful conversion of an empty range of
a nil array.
RCS file: /cvsroot/sbcl/sbcl/src/code/octets.lisp,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -d -r1.24 -r1.25
--- octets.lisp 11 Nov 2009 13:21:37 -0000 1.24
+++ octets.lisp 11 Nov 2009 13:52:19 -0000 1.25
@@ -74,20 +74,13 @@
;;; Of these, the only one truly likely to be of interest to calling
;;; code is end-of-input-in-character (in which case it's likely to
;;; want to make a note of octet-decoding-error-start, supply "" as a
;;; replacement string, and then move that last chunk of bytes to the
;;; beginning of its buffer for the next go round) but they're all
-;;; provided on the off chance they're of interest. The next most
-;;; likely interesting option is overlong-utf8-sequence -- the
-;;; application, if it cares to, can decode this itself (taking care
-;;; to ensure that the result isn't out of range of CHAR-CODE-LIMIT)
-;;; and return that result. This library doesn't provide support for
-;;; that as a conforming UTF-8-using program is supposed to treat it
-;;; as an error.
+;;; provided on the off chance they're of interest.
(define-condition octet-decoding-error (character-decoding-error)
((array :initarg :array :accessor octet-decoding-error-array)
Get latest updates about Open Source Projects, Conferences and News.