Ticket #439 (closed defect: fixed)

Opened 8 years ago

Last modified 8 years ago

Gray Streams malfunction

Reported by: dbmcclain Owned by: gb
Priority: normal Milestone:
Component: Runtime (threads, GC) Version:
Keywords: Gray Streams Cc:


(defclass ubyte-stream ()


(defmethod cl:stream-element-type ((stream ubyte-stream))

'(unsigned-byte 8))

;; --------------------------------------------------------------------------------

(defclass ubyte-output-stream (ccl:fundamental-binary-output-stream ubyte-stream)

((arr :accessor uos-arr :initform (make-array 0

:element-type '(unsigned-byte 8) :adjustable t :fill-pointer t))))

(defun make-ubyte-output-stream ()

(make-instance 'ubyte-output-stream))

Now try:

(defparameter s (make-ubyte-output-stream))

(write-byte 15 s) -->> boom!

value #<UBYTE-OUTPUT-STREAM #x9224AEE> is not of the expected type (AND


[Condition of type TYPE-ERROR]

Yet, if I do the following:

(typep s '(and output-stream ccl::binary-stream)) ==> t

Change History

comment:1 Changed 8 years ago by gb

  • Status changed from new to assigned

If the error message had said something like "FUNDAMENTAL-BINARY-OUTPUT-STREAM is an abstract class; a direct instance of that abstrace class isn't really capable of doing I/O ..." - or somehow said that more succinctly - I suppose that that might have been clearer.

A concrete subclass of FUNDAMENTAL-BINARY-OUTPUT-STREAM - like UBYTE-OUTPUT-STREAM - can implement methods that allow instances of that class to do I/O.

(defmethod stream-write-byte ((stream ubyte-output-stream) b)
  "possibly what's intended"
  (vector-push-extend b (uos-arr stream))

It's actually the case that nothing in the Gray streams protocol (beyond goodwill and common sense) prohibits defining a STREAM-WRITE-BYTE method on (for instance) a CHARACTER-INPUT-STREAM, so the default STREAM-WRITE-BYTE method on STREAM could plausibly just complain that it's being called because no useful method was applicable. (Or that method could remain undefined and result in NO-APPLICABLE-METHOD.) I dunno; the most common case where that method's reached - and where goodwill and common sense are involved - involves things like trying to do output on an input stream or do binary output to a character stream, and it's not clear that changing things around so that the error message is clearer in pathological cases is a good idea.

Other than the fact that the error message is misleading in this particular pathological case, it doesn't seem that there's a bug here: your example should have gotten an error.

Please close this unless you think that there's something valid here.

comment:2 Changed 8 years ago by dbmcclain

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.