[Openmcl-devel] macptrs and fasl file

[Matt Claus]

Wow, thanks Gary. I pulled down the latest source and it works great. I 
sure appreciate your help and informative responses.

Regards,
Matt

Gary Byers wrote:
> IIRC, SAVE-APPLICATION treats pointers to the low 64K and the high 64K 
> of the
> address space as being constants (things outside of that wrapped-around 
> range
> have their type changed to "dead-macptr".)  Those limits are somewhat 
> arbitrary,
> but it's pretty unlikely that addresses in the high or low ends of the 
> address
> space refer to dynamically allocated things.  My first reaction is to think
> that COMPILE-FILE should probably behave the same way (it currently refuses
> to deal with a non-null pointer constant.)
> 
> There are a few other (very minor) issues related to pointer constants:
> 
>  - pointers can contain at least some basic information about the type of
>    thing that they're pointing to.  I'm not sure that it makes sense to
>    treat a pointer that has this type information as a constant.  (Things
>    like #$IDC_ARROW are untyped, IIRC.)
> 
>  - some pointers contain some extra info that makes them "GCable", which
>    means that the GC may have a way of deallocating (finalizing) the 
> foreign
>    object when the lisp MACPTR object becomes garbage.  It wouldn't make
>    much sense to try to serialize a GCable pointer (but it probably 
> wouldn't
>    make much sense to create a GCable pointer to the high or low ends of 
> the
>    address space, either.)
> 
> I made that change in the trunk a little while ago; this issue comes up
> often enough that it or something similar should go in the next release, I
> think.
> 
> 
> On Wed, 7 Oct 2009, Matt Claus wrote:
> 
>> Greetings,
>>
>> I noticed some time ago that the mswin.lisp example loads and works fine
>> but fails to compile. I've had similar problems with my own windows
>> applications.
>>
>> ? (compile-file "c:/wk/ccl/examples/mswin.lisp")
>> > Error: Can't dump #<A Foreign Pointer #x7F00> - unknown type
>> > While executing: CCL::FASL-UNKNOWN, in process listener(1).
>>
>> The problem reduces to this win32 call:
>>
>> (#_LoadCursorA (%null-ptr) #$IDC_ARROW)
>>
>> The second argument to LoadCursor is defined to be a pointer to a string
>> naming the resource to load.
>>
>> Some win32 functions defined to accept named resources will also accept
>> an integer resource identifier packed into the low word of this pointer
>> like #$IDC_ARROW.
>>
>> I understand that it doesn't make sense to serialize the
>> value of a foreign pointer but in this case the value is really a
>> constant rather than a real pointer to some address.
>>
>> Is there some general way to convey this fact to the compiler?
>>
>> Cheers,
>> Matt
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>