Exported pointer variables

[dsar]

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

[dsar]

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]

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]

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]

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]

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.