[Openmcl-devel] make-heap-buffer question
gb at clozure.com
Mon Sep 20 23:09:22 EDT 2004
On Sun, 19 Sep 2004, Cyrus Harmon wrote:
> So I'm not sure exactly how to use the make-heap-buffer,
> make-heap-ivector stuff, or why it's in streams, for that matter, but
> this seems a bit odd:
> (multiple-value-bind (buf p)
> (ccl::make-heap-buffer '(unsigned-byte 32) 256)
> (print (array-dimensions buf))
> (setf (aref buf 0) #x7f7f7f7f)
> (setf (aref buf 1) #xaabbccdd)
> (setf (aref buf 1023) #xdeadbeef)
> (let ((*print-base* 16))
> (print (aref buf 0))
> (print (aref buf 1))
> (print (aref buf 1023)))
> (print p))
> gives the following results:
> #<A Mac Pointer #x10A2CC>
> I can understand buf beingg 1024 _bytes_ (in the normal 8-bit sense)
> long, but it looks to me like it's 1024 unsigned-byte 32's long. Is
> this a bug or am I missing something?
Sorry that I missed this the first time that I replied.
You're right. The very-lowest-level CCL::%MAKE-HEAP-IVECTOR takes
subtype size-in-octets &optional size-in-elements
and there's nothing "optional" about the size-in-elements (I think that
this was translated from 68K assembler about 10 years ago ...).
When CCL::MAKE-HEAP-BUFFER calls it, it calls it with the last two
arguments reversed, so whenevever the size-in-octests and size-in-elements
differ, the pointer is too small and the vector too large.
(with-open-file (foo "foo.bin" :element-type '(unsigned-byte 16))
could run into this; this is not only a bug, but a potentially bad one.
(The other function that I keep mailing out - MAKE-HEAP-IVECTOR -
passes the right arguments to the lower-level function.)
More information about the Openmcl-devel