Attached is a patch (including test cases) that ensures that
READ-SEQUENCE signals a TYPE-ERROR when reading into an incompatible
In 220.127.116.11, 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 18.104.22.168?
0.9.17 builds 22.214.171.124 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,
From: Juho Snellman <jsnell@ik...> - 2006-12-29 01:41:41
"Antonio Martinez" <antonio.martinez.shotton@...> writes:
> Hi there,
> Attached is a patch (including test cases) that ensures that
> READ-SEQUENCE signals a TYPE-ERROR when reading into an incompatible
Thanks, looks good. Committed.