[cmucl-ticket] [cmucl] #42: read-sequence vs unicode

[cmucl]

#42: read-sequence vs unicode
---------------------+------------------------------------------------------
  Reporter:  rtoy    |       Owner:  somebody
      Type:  defect  |      Status:  new     
  Priority:  major   |   Milestone:          
 Component:  Core    |     Version:  20b     
Resolution:          |    Keywords:          
---------------------+------------------------------------------------------
Description changed by rtoy:

Old description:

> Cmucl has been able to use {{{READ-SEQUENCE}}} to read octets (and other
> integers types) from character streams.  With the introduction of Unicode
> support, this no longer works correctly in general.  The data that is
> read is not done from the last position, and the data that is read is not
> necessarily reflected in the next {{{READ-CHAR}}}.  That is, {{{READ-
> CHAR}}} might re-read the data that {{{READ-SEQUENCE}}} already read.
> (This depends on how much data has been read, and the internal stream
> buffering.)
>
> However, if the external format is :iso8859-1, then {{{READ-SEQUENCE}}}
> behaves as it used to.  Hence, as a workaround, the user can set the
> external format to :iso8859-1 before {{{READ-SEQUENCE}}} and set it back
> afterwards.  This works as expected.
>
> Perhaps {{{READ-SEQUENCE}}} should do that itself?  (Appropriately
> wrapping everything in {{{UNWIND-PROTECT}}} so that the stream external
> format isn't unexpected modified.)

New description:

 Cmucl has been able to use {{{READ-SEQUENCE}}} to read octets (and other
 integers types) from character streams.  With the introduction of Unicode
 support, this no longer works correctly in general.  The data that is read
 is not done from the last position, and the data that is read is not
 necessarily reflected in the next {{{READ-CHAR}}}.  That is, {{{READ-
 CHAR}}} might re-read the data that {{{READ-SEQUENCE}}} already read.
 (This depends on how much data has been read, and the internal stream
 buffering.)

 However, if the external format is :iso8859-1, then {{{READ-SEQUENCE}}}
 behaves as it used to.  Hence, as a workaround, the user can set the
 external format to :iso8859-1 before {{{READ-SEQUENCE}}} and set it back
 afterwards.  This works as expected.

 Perhaps {{{READ-SEQUENCE}}} should do that itself?  (Appropriately
 wrapping everything in {{{UNWIND-PROTECT}}} so that the stream external
 format isn't unexpectedly modified.)

--

-- 
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/42#comment:1>
cmucl <http://common-lisp.net/project/cmucl>
Cmucl is a high-performance, free Common Lisp implementation.