[Oberon] ORD for typecasting Pointers

[Andreas Pirklbauer]

    >
    > If not a bug, at best I would classify the ability to use ORD to typecast
    > a pointer to an INTEGER as a 'loophole'.Refer to the Section titled
    > 'Loopholes' in 'Good Ideas, Through the Looking Glass', Niklaus Wirth 2005.
    >
    > https://people.inf.ethz.ch/wirth/Articles/GoodIdeas.pdf
    >

Agreed. So if one can write a line like the following

    PROCEDURE GetPat*(fnt: Font; ch: CHAR; VAR dx, x, y, w, h, patadr: INTEGER);
      ...
    BEGIN …  patadr := ORD(fnt) + FontDescSize + pa
   
then that clearly is a loophole: one could accidentally pass an incorrect
value for ‘FontDescSize' or ‘pa’, thereby making ‘patadr' point to a memory
location *outside* the range of the pattern array (no more range checks).

The real issue is already in the parameter ‘patadr' of Fonts.GetPat, i.e. it
really is ADDRESS, which is interpreted as such in e.g. CopyPattern.

So I have created a variant of Fonts which returns a pointer to a dynamically
allocated (pattern) byte array (possible in Extended Oberon,  but not in Project
Oberon 2013) instead of an integer (=memory location) ‘patadr'.

But then one would also need to modify all procedures that access the
pattern, e.g. Display.CopyPattern, to use that pointer instead of an absolute
address ‘patadr’. When this is done, one gains type safety, at the expense
of sacrificing performance in CopyPattern etc (where performance is critical).

Conclusio?

So it may be better to use SYSTEM.ADR instead of ORD then in Fonts.
Then, at least the “loophole is honestly displayed”, as N.Wirth would call it
(see his paper, section on Loopholes).