[Oberon] Fighting a dragon ...

[Michael Schierl]

Hello,

>> The limits of FLOOR and FLT are not described in the Oberon report, as it is implementation dependent.
>> Even the number of bytes of an INTEGER is not defined in Oberon; however, you can detect the implementation limit with SYSTEM.SIZE(INTEGER).
>> Only BYTE is defined in Oberon to hold values from 0..255.

> That functions like FLOOR and FLT have some upper and lower limits should not come as a surprise. But it is unfortunate that even experienced programmers have trouble finding them.


To me it was a bit of a surprise. Even the language which is infamous
for its "nasal deamons" (C) has a clear specification for this.

<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>, chapter
6.3.1.4 about conversions:

> 6.3.1.4 Real floating and integer
>
> 1. When a finite value of real floating type is converted to an integer
>    type other than _Bool, the fractional part is discarded (i.e., the
>    value is truncated toward zero). If the value of the integral part
>    cannot be represented by the integer type, the behavior is
>    undefined.[50])
>
> 2. When a value of integer type is converted to a real floating type, if
>    the value being converted can be represented exactly in the new type,
>    it is unchanged. If the value being converted is in the range of
>    values that can be represented but cannot be represented exactly, the
>    result is either the nearest higher or nearest lower representable
>    value, chosen in an implementation-defined manner. If the value being
>    converted is outside the range of values that can be represented, the
>    behavior is undefined.
>
> [50] The remaindering operation performed when a value of integer type
> is converted to unsigned type need not be performed when a value of real
> floating type is converted to unsigned type. Thus, the range of portable
> real floating values is (−1, Utype_MAX+1).

Anyway, good to know that Oberon has implementation-specific limits
here. The one use of FLT in ORS.Mod (only single digit) is safe - the
other calls in Math.Mod and Texts.Mod (as well as the FLOOR calls)
probably need to be examined, as they do not looks safe for me at first
inspection.


Regards,


Michael