[Oberon] Question about Oberon semantics of VAR parameters
joerg.straube at iaeth.ch
Mon Dec 9 09:15:52 CET 2019
As Chris pointed out there are other undocumented features in the compiler.
We might collect and document them. In most (if not all) cases you can live without them or program around them. They come in handy if you have certain low level needs.
The current discussed topic is about loosening the strict typing rules. You mentioned ANYREC and ANYPTR; this is a complete opening up of any type checking.
The undocumented feature is something in between: it allows parameter passing of any variable as long as the size fits. This has the benefit that the low layer module offering this capability just sees the passed variable as a specific nbr of bytes. And the higher level module passing the variable declares its logical meaning. But the size of the two involved views of memory must fit. This is better than ANYREC.
BTW: Standard Oberon-07 offers (kind of) ANYREC. The discussed topic could be rewritten as follows:
ANYREC = RECORD END;
Sector = RECORD (ANYREC) buf: ARRAY 1024 OF BYTE END;
PROCEDURE GetSector*(src: INTEGER; VAR dst: ANYREC);
FileHeader = RECORD (Kernel.ANYREC)
name: ARRAY 32 OF CHAR;
aleng, bleng, date: INTEGER;
ext: ARRAY 12 OF INTEGER;
sec: ARRAY 64 OF INTEGER;
fill: ARRAY 672 OF BYTE
With this ANYREC method there is no size checking involved.
> Am 09.12.2019 um 05:43 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>> There are several more in the Project Oberon compiler. I won't mention the others for fear of alarming you further. If they haven't been of any concern to you yet then there's no need to worry about them now.
> I propose that the compiler documentation should always provide a chapter "All undocumented features of this compiler - please delete this file before opening it".
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon