[Antik-devel] Reader macro for sharp-m returns literal foreign-array (patch included)

[James Wright]

Hi,

I have encountered the following problem a couple of times before,
although not as reproducibly as the memory corruption issue from my
previous message:  If I use the #m reader macro in a function
somewhere, dump an SBCL core image, load the image, and call the
function, I get memory corruption.  I have mostly dealt with it up
until now by not using the #m() notation in anything that I plan to
dump to a binary.

I believe that the cause is that the #m macro returns a foreign-array
object directly (when foreign-array is the default grid type).  If it
returned a `make-grid' form instead, it would operate identically on
e.g. the REPL.  It would have the advantage, however, of being usable
in a dumped image, since the array would be created at run-time
instead of at read-time, and hence no foreign-pointers would be saved
into the image.

I've attached a patch that changes the #m reader macro to return a
creation form instead of a literal.  I hope you'll consider adding it.
 I've pasted a repl session below that demonstrates the difference.

Thanks,
      James

;;; Before the patch
GRID> (read-from-string "#m(1d0 2d0)")
#m(1.000000000000000d0 2.000000000000000d0)
11
GRID> #m(1d0 2d0)
#m(1.000000000000000d0 2.000000000000000d0)

;;; After the patch
GRID> (read-from-string "#m(1d0 2d0)")
(MAKE-GRID '((FOREIGN-ARRAY) DOUBLE-FLOAT) :INITIAL-CONTENTS '(1.0 2.0))
11
GRID> #m(1d0 2d0)
#m(1.000000000000000d0 2.000000000000000d0)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Make-sharp-m-reader-macro-return-a-grid-make-grid-fo.patch
Type: text/x-patch
Size: 1426 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/antik-devel/attachments/20111209/0706f1a2/attachment.bin>