Trying to write a plugin - how to store a pointer

[Andreas Raab]

 > Is there a good way to make it future proof for 64 bit addresses?

Generally, it's safer to use indexes (handles) that the VM maps to 
appropriate pointers... wait ... I wrote that before, didn't I?

;-)


Todd Blanchard wrote:
> My plan is to add the class containing the pointer to the startup/ 
> shutdown lists and make them zombies (I can't reasonably re-animate  
> them with full state I don't think).
> 
> So I've got this:
> 
> primNewRuntime: bytesToAllocate
> 
>     | rtid size |
> 
>     self export: true.
>     self var: #rtid type: 'void *'.
>     self var: #size type: 'unsigned int'.
>     size := interpreterProxy positive32BitValueOf:  bytesToAllocate.
>     rtid := self cCode: 'LIB_NewRuntime(size)'.
>     ^interpreterProxy positive32BitIntegerFor:  rtid.
> 
> Look OK?
> Is there a good way to make it future proof for 64 bit addresses?   Off 
> the top of my head I can think of:
> 
> primNewRuntime: bytesToAllocate
> 
>     | rtid size |
> 
>     self export: true.
>     self var: #rtid type: 'void *'.
>     self var: #size type: 'unsigned int'.
>     (self cCode: 'sizeof(void*)') = 4 ifTrue:
>     [
>         size := interpreterProxy positive32BitValueOf:  bytesToAllocate.
>         rtid := self cCode: 'LIB_NewRuntime(size)'.
>         ^interpreterProxy positive32BitIntegerFor:  rtid.
>     ]
>     ifFalse:
>     [
>         size := interpreterProxy positive64BitValueOf:  bytesToAllocate.
>         rtid := self cCode: 'LIB_NewRuntime(size)'.
>         ^interpreterProxy positive64BitIntegerFor:  rtid.
>     ]
> 
> Maybe you know a better way?
> 
> On Jan 23, 2006, at 3:29 PM, John M McIntosh wrote:
> 
>> Although this seems correct at first, you run into trouble because  
>> SmallInteger has a finite range smaller than a 32bit integer.
>> Ignoring the 64bit needs  you would pass the value in as a Oops  then 
>> do this
>>
>>     pv := interpreterProxy positive32BitValueOf:  anAddressOops.
>> or perhaps
>> use positive64BitIntegerFor:  ?
>>
>> on return you do this to pass the bits back.
>>     ^ interpreterProxy positive32BitIntegerFor:  address
>>
>> It's likely you need to look at finalization and registering an  
>> external object (Smalltalk registerExternalObject: )
>> to ensure you free things when the smalltalk object is GCed, and to  
>> check to see if the object is still valid save after an image  restart to
>> prevent passing in a bogus address which your C plugin would  
>> cheerfully attempt to use.  MPEGFile has some example code in it.
>>
>>
>> On 23-Jan-06, at 3:01 PM, Todd Blanchard wrote:
>>
>>> For various reasons, I'm wanting to build a plugin to a library  that 
>>> requires me to hold onto pointers to things.  This means I  need to 
>>> store the pointer in an ivar in a squeak object and use it  on 
>>> subsequent calls.
>>>
>>> Can I get away with using a SmallInteger for this?  Basically  doing 
>>> something like:
>>>
>>> primNewContext
>>>     | ctx |
>>>
>>>     self export: true.
>>>     self primitive: 'primCreateContext' parameters: #().   
>>>     self var: #ctx type: 'int'.
>>>     ctx := self cCode: 'LIB_NewContext()'.
>>>     ^ctx.
>>>
>>> primDestroyContext: ctx
>>>     self export: true.
>>>     self primitive: 'primDestroyContext' parameters: #(SmallInteger).   
>>>     self cCode: 'LIB_DestroyContext((void*)ctx)'.
>>>
>>> Or is this evil and I should consider a different technique?
>>> If this is evil, what is the good way to store external addresses  in 
>>> ivars?
>>>
>>> Thanks
>>
>>
>> -- 
>> ====================================================================== 
>> =====
>> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
>> Corporate Smalltalk Consulting Ltd.  http:// www.smalltalkconsulting.com
>> ====================================================================== 
>> =====
>>
> 
>