[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