[Oberon] When is it safe to unload a module?

Chris Burrows chris at cfbsoftware.com
Sat Aug 4 03:03:00 CEST 2018


> -----Original Message-----

> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of

> Andreas Pirklbauer

> Sent: Saturday, 4 August 2018 9:42 AM

> To: ETH Oberon and related systems

> Subject: [Oberon] NAstrobe for RISC5 on Pepino

> 

> Apart from client references (where another module imports M),

> references to a module can also be in the form of type tags

> (addresses of type descriptors) in dynamic objects of other modules

> (allocated via the predefined procedure NEW) pointing to descriptors

> of types declared in the module, or in the form of procedure

> variables installed in static or dynamic objects of other modules

> referring to procedures declared in the module.

> 

> So one has the following types of  references :

> 

> 1. Client reference

> 2. Type (tag) references

> 3. Procedure (variable) references

> 

> FPGA Oberon checks only 1., but not 2. or 3.

> 

 

Thank you for the clarification. I would have been concerned if Client references weren’t working properly! 

 

I’ve no doubt that if somebody is determined to find ways to break the system they'll succeed. I suspect I don't need to worry too much about 2 and 3 affecting me but I can’t be sure. 

 

Consequently, I'd be interested to see a simple *minimal* test application for each of the use cases 2 or 3 assuming that:

 

1. They are not using SYSTEM or any other devious means to bypass system security. 

 

2. It's the sort of programming technique you'd expect to see in a regular Oberon application (as opposed to kernel-level, device-driver programming etc.). 

 

Regards,

Chris

 

Chris Burrows

CFB Software

http://www.astrobe.com/RISC5

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180804/61c7a752/attachment.html>


More information about the Oberon mailing list