John,

> Now it seems this has been done in the past, and this work is a bit  
> nasty dangerous because
> leaving a pointer object around with un-initialized bits and then  
> invoking the GC logic will trash things.
> So those that have done this in the past, should look and comment, in  
> case I missed something.

  your change looks ok.  Although what I tried in tha past was only
for the non-pointer objects so I really didn't run into the *real*
problem...

> There are some questions, for example calling
> Interpreter>>primitiveClipboardText
> First we ask the OS support routines the size of the clipboard, then we  
> allocate the space, then
> get the data. But what if the OS support routine does a callback and  
> causes a GC? Well in this case
> our data is of Class String, so no issue, however if we are told there  
> are 100 bytes, but only get 90,
> then 10 are junk, versus hex 00.  {MMMM on second thought I think this  
> raises an issue because we are assuming
> the object won't move during the call to the primitive to get the  
> clipboard data, so I think there is no exposure}

  Probably, we should create another string that is the size of
actual read data.

  Yes, the clipboard content can change during the call to
#clipboardSize and clipboardRead in the primitive.

  For embedded application, one would want to add user-level access to
the no-fill primitive for, say, Bitmap or those objects.  That could
improve the performance on slow computers.  But this is another
issue...

-- Yoshiki