[Oberon] ORD for typecasting Pointers
joerg.straube at iaeth.ch
Sat Sep 5 08:24:07 CEST 2020
Fonts should import Display!
The type Pattern should be in Display, as only Display knows the bit layout if you add colors to the system.
> Am 05.09.2020 um 07:44 schrieb Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>:
>> 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.
> 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).
> 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).
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon