augustk wrote:... my standpoint is that the inability to modify an exported field though an exported pointer (as in my example) represents a minor compiler bug
That is not correct. Unless I have misunderstood what you are saying I believe you have 'got the wrong end of the stick'. The system is designed to try to prevent
you from modifying an element of an exported record variable - that part is working fine.
a problem is that you can
modify an element of an exported record variable by accessing it via an aliased pointer as you have shown.
My reasoning is as follows:
In general the priciples of 'information hiding' make it undesirable to allow the export of variables
from a module. A variable should only be accessible to a client module via an exported 'getter' (read) or 'setter' (write function). The latter allows any changes to the variable to be validated (e.g. check that it is within an allowable range) by the defining module.
However, for Oberon, this was considered to be too cumbersome and / or involved significant processing overhead for the simple case of scalar variables. Hence, the rule was relaxed by allowing scalar variables to be exported so that they could be read. They can still only be modified via an exported 'setter' (write function).
There was no intention to allow any variable or element of a variable to be changed by a client module except via a setter function.
What you have described is a 'loophole' in the system. Fortunately it is unlikely to happen accidentally in practice as it would be expensive to detect at runtime. The best defence is for the programmer to avoid exporting pointers and to always use getter / setter functions.