[Sbcl-devel] [patch] Ensure {READ, WRITE}-SEQUENCE signal TYPE-ERRORs when used with incompatible sequences

[Antonio M. <ant...@gm...>]

Hi there,

Attached is a patch (including test cases) that ensures that
READ-SEQUENCE signals a TYPE-ERROR when reading into an incompatible
sequence.

In 1.0.0.18, READ-SEQUENCE uses a READ-BYTE loop for most sequences,
but not for (UNSIGNED-BYTE 8) or (SIGNED-BYTE 8) vectors; in these two
cases, the (presumably) faster READ-N-BYTES is used instead.

So far, so good.  The problem is that the stream and vector element
types aren't checked for consistency, so it is possible to read bytes
from an (UNSIGNED-BYTE 8) stream into a (SIGNED-BYTE 8) sequence
directly (with the implicit coercion implied), and vice versa.

Although the CLHS says of READ-SEQUENCE that it:

  "Might signal an error of type type-error if an element read from
   the stream is not a member of the element type of the sequence."

in the "Exceptional Situations" section, which wouldn't require that
the implementation signal a TYPE-ERROR, it then says that:

  "read-sequence is identical in effect to iterating over the
   indicated subsequence and reading one element at a time from stream
   and storing it into sequence, but may be more efficient than the
   equivalent loop. An efficient implementation is more likely to
   exist for the case where the sequence is a vector with the same
   element type as the stream."

in the "Notes" section.  Not storing the same numbers depending on
whether the sequence is read into a LIST or a (VECTOR (SIGNED-BYTE 8))
seems to violate the latter quote, which is why the patch.

WRITE-SEQUENCE suffers from the same behaviour, so I modified
WRITE-SEQUENCE, too.  I _enabled_ the fast code path for (VECTOR
(SIGNED-BYTE 8)) when the stream is compatible; any particular reason
why only (VECTOR (UNSIGNED-BYTE 8)) has a fast path in 1.0.0.18?

0.9.17 builds 1.0.0.18 with the attached patch.

Comments welcome, as always; in particular,
compatible-vector-and-stream-element-types-p, while descriptive, may
be a bit of a mouthful.

                 Hope this helps,

                        --Tony