[Openmcl-devel] make-heap-buffer question

Gary Byers gb at clozure.com
Mon Sep 20 20:09:22 PDT 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:
> (1024)
> 7F7F7F7F
> #<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 mailing list