Exported pointer variables

Topics related to the use of Oberon language features

Re: Exported pointer variables

Postby 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

Postby 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).
dsar
 
Posts: 8
Joined: Wed Oct 10, 2012 9:12 pm

Re: Exported pointer variables

Postby 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: 369
Joined: Fri Dec 31, 2010 12:30 pm

Re: Exported pointer variables

Postby 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.
cfbsoftware
Site Admin
 
Posts: 369
Joined: Fri Dec 31, 2010 12:30 pm

Re: Exported pointer variables

Postby 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.
augustk
 
Posts: 52
Joined: Mon Sep 05, 2011 5:21 pm
Location: Sweden

Re: Exported pointer variables

Postby 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.
cfbsoftware
Site Admin
 
Posts: 369
Joined: Fri Dec 31, 2010 12:30 pm

Previous

Return to Oberon Language

cron