This voting is about merging the changes of topic branch issue-#51
(support for ANYPTR/SYSTEM.PTR in Meta.LookupPath) to master.
For the issue see http://redmine.blackboxframework.org/issues/51.
For the changes see http://redmine.blackboxframework.org/pr ... 41c1c7378e.
The changes are based on the proposal in CPC 1.7 rc5 plus a little simplification
and the required docu update.
They remove a restriction without any incompatibilities or other observable changes.
Gentlemen, please cast your vote.
- Josef
issue-#51 support for ANYPTR/SYSTEM.PTR in Meta.LookupPath
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
issue-#51 support for ANYPTR/SYSTEM.PTR in Meta.LookupPath
Last edited by Josef Templ on Wed May 27, 2015 9:36 am, edited 1 time in total.
Re: issue-#51 support for ANYPTR/SYSTEM.PTR in Meta.LookupPa
Does this come into the category of bug fix or new feature?
And I don't know anything about sysPtrType - have I missed something?
Regards
And I don't know anything about sysPtrType - have I missed something?
Regards
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#51 support for ANYPTR/SYSTEM.PTR in Meta.LookupPa
you didn't miss a lot.
It is only for SYSTEM level programming and can hold any
type of pointer even a pointer to an array. But it is used only in
system dependent code (IMPORT SYSTEM), so keep avoiding it if possible.
I think it is also undocumented.
- Josef
It is only for SYSTEM level programming and can hold any
type of pointer even a pointer to an array. But it is used only in
system dependent code (IMPORT SYSTEM), so keep avoiding it if possible.
I think it is also undocumented.
- Josef
Re: issue-#51 support for ANYPTR/SYSTEM.PTR in Meta.LookupPa
Does this mean we should update the Platform-Specific-Issues Docu to include SYSTEM.PTR?Josef Templ wrote:It is only for SYSTEM level programming and can hold any
type of pointer even a pointer to an array. ... I think it is also undocumented.
- Josef
My guess was that ANYPTR would match to any pointer managed by the BlackBox garbage collector, and SYSTEM.PTR
would match to any non-tagged memory as used by foreign DLLs. But that is purely a guess - I simply don't know.
And I am curious; how do you guys know about SYSTEM.PTR when there is no mention of it anywhere?
But I have voted to include the change anyway.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#51 support for ANYPTR/SYSTEM.PTR in Meta.LookupPa
SYSTEM.PTR was always available in Oberon, long time before CP.
ANYPTR is only allowed to point to a record (TYPE ANYPTR = POINTER TO ANYREC;)
and is a CP specific refinement of SYSTEM.PTR.
Either ominc forgot to document SYSTEM.PTR or they tried to hide it in order to promote ANYPTR.
Untagged pointers are a little different. They tell the runtime system to ignore
such pointers in the garbage collector. Any pointer can be marked untagged.
Unless marked as untagged, ANYPTR and SYSTEM.PTR are tracked by the garbage collector
just like any other pointer.
- Josef
ANYPTR is only allowed to point to a record (TYPE ANYPTR = POINTER TO ANYREC;)
and is a CP specific refinement of SYSTEM.PTR.
Either ominc forgot to document SYSTEM.PTR or they tried to hide it in order to promote ANYPTR.
Untagged pointers are a little different. They tell the runtime system to ignore
such pointers in the garbage collector. Any pointer can be marked untagged.
Unless marked as untagged, ANYPTR and SYSTEM.PTR are tracked by the garbage collector
just like any other pointer.
- Josef