[Oberon] Wrong output of Texts.WriteReal and Texts.WriteRealFix in PO

[Chris Burrows]

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Hans
> Klaver
> Sent: Sunday, 4 October 2020 7:08 AM
> To: ETH Oberon and related systems
> Subject: [Oberon] Wrong output of Texts.WriteReal and Texts.WriteRealFix in
> PO
> 
> I wonder if it is known that the output of the present PO version of
> Texts.WriteReal and Texts.WriteRealFix for various borderline values can be
> completely false due to untrapped overflow of FLOOR(x)? Although it is
> acceptable that floating point representation of real numbers produces
> round-off errors, the output of obviously wrong values is undesirable.
> 
> While looking into this I compared the output of these procedures with the
> same in my first Oberon (DOS Oberon V1.4, which I ordered from ETH Zurich
> in the early nineties). I don't have the source code of that early Oberon
> version, but I suppose it uses the source as published in the 1992 Project
> Oberon book. For the present PO version prof. Wirth rewrote these
> procedures, originally by J. Gutknecht.
> 

Traps that are implemented in Project Oberon 2013 are defined in section 12.7.10:

1 array index out of range
2 type guard failure
3 array or string copy overflow
4 access via NIL pointer
5 illegal procedure call
6 integer division by zero
7 assertion violated

Note that this differs from the traps defined in section 12.9 of the 1992 / 2005 version of Project Oberon: 

2 Address trap: typically reference via NIL pointer 
3 Floating-point trap: overflow 
6 Division by zero 
7 Flag trap: invalid index 
13 Integer trap (or invalid index): overflow 
18 Type guard failure

You will see that Floating-point and Integer overflow were detected and trapped in the older system but not in the current one. There are valid arguments for and against either approach. E.g. a trade-off between efficiency and protecting programmers from themselves.

Consequently, programmers of any Project Oberon 2013 applications that could result in numeric overflow need to ensure that the desired resulting behaviour is clearly defined in the requirements and that they design, program and test their applications accordingly.

Regards,
Chris

Chris Burrows
CFB Software
https://www.astrobe.com