Exported pointer variables

Topics related to the use of Oberon language features
dsar
Posts: 8
Joined: Wed Oct 10, 2012 9:12 pm

Re: Exported pointer variables

Post by dsar » Thu Oct 11, 2012 7:55 am

Uhm, I don't get your interpretation, then you consider public field identifers in a record as read only variables?

dsar
Posts: 8
Joined: Wed Oct 10, 2012 9:12 pm

Re: Exported pointer variables

Post by dsar » Thu Oct 11, 2012 8:29 pm

Both Oberon-2 and Component Pascal reports are clear for their read-only export mark:
4. Declarations and Scope Rules
[...]
Variables and record fields marked with a minus in their declaration are read-only in importing modules.
4. Declarations and Scope Rules
[...]
Variables and record fields marked with " - " in their declaration are read-only (variables and fields) or implement-only (methods) in importing modules.
My interpretation is still that exported record fields in Oberon-07/11 are always read-write, also if they are part of a variable declared in the module's scope (like in the first example of augustk).

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: Exported pointer variables

Post by cfbsoftware » Mon Oct 15, 2012 10:05 am

The 2011 revision of Oberon is a new revision of Oberon - it is not necessarily backwards-compatible with older revisions. Similarly, Oberon-2 and Component Pascal are different dialects of Oberon - you cannot use them as a guide when interpreting Oberon's language rules.

If you want to use a client module to modify the value of any variable (a scalar, an array element, a pointer, a field of a record, an entire record, an entire array etc. etc.) that is declared in an external module then you have to do it via a procedure which is also declared in the external module.

Code: Select all

MODULE M;

   TYPE
      T* = POINTER TO RECORD
         x*: INTEGER
      END;

   VAR t*: T;

PROCEDURE* Setx*(x: INTEGER);
BEGIN
  t.x := x
END Setx;

BEGIN
   NEW(t);
   t.x := 0;
...
...
This is not a problem in Astrobe - particularly with some of the recent improvements we have been working on. The example above only results in the execution of 2 more instructions (7 instead of 5) than it would if the variable could be modified directly.

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: Exported pointer variables

Post by cfbsoftware » Sat Mar 01, 2014 6:04 am

The most recent (dated 22 Feb 2014) published copy of the Oberon Report (Revision 1.10.2013) now says:
Variables are always exported in read-only mode.
instead of:
Variables cannot be exported, with the exception of those of scalar types in read-only mode.
Array and Record variables can be exported in read-only mode In Astrobe for Cortex-M3 v5.0 and later.

augustk
Posts: 54
Joined: Mon Sep 05, 2011 5:21 pm
Location: Sweden

Re: Exported pointer variables

Post by augustk » Tue Mar 11, 2014 10:37 am

Variables are always exported in read-only mode.
This is good news, at least for non-pointer variables. It implies that each exported constant can be changed to an exported variable (if its value needs to be computed at run-time) without changing the client modules. Before we could not export character arrays, for instance.

The semantics of exported pointer variables is subtle though. Consider the following module:

Code: Select all

MODULE M;

	TYPE T* = POINTER TO RECORD x*: INTEGER END;

	VAR 
		p*: T;
		q*: POINTER TO RECORD x*: INTEGER END;
		
END M.
In a client module the field M.p.x can be modified by a variable of type M.T whereas the field M.q.x cannot be modified.

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: Exported pointer variables

Post by cfbsoftware » Fri Mar 14, 2014 11:55 pm

augustk wrote:The semantics of exported pointer variables is subtle though. Consider the following module:

Code: Select all

MODULE M;

	TYPE T* = POINTER TO RECORD x*: INTEGER END;

	VAR 
		p*: T;
		q*: POINTER TO RECORD x*: INTEGER END;
		
END M.
In a client module the field M.p.x can be modified by a variable of type M.T whereas the field M.q.x cannot be modified.
The way we have implemented this feature in the upcoming v5.1 of Astrobe the following code results in Error: read-only for all five of the following assignments:

Code: Select all

VAR 
  p: M.T;

BEGIN
  NEW(M.p);
  NEW(M.q);
  M.p.x := 0;
  M.p := p;
  M.q.x := 0;
However, if you wanted to you could circumvent this protection e.g. by aliasing the pointer:

Code: Select all

  p := M.p;
  p.x := 0;
or by using SYSTEM features. If you want to protect against these techniques you should not export the pointer variables and only allow access to them via procedures.

Locked