[Openmcl-devel] macptrs and fasl file

[Gary Byers]

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
>
>