[Oberon] Undefined behaviour (was: Easter eggs in Oberon)

Michael Schierl schierlm at gmx.de
Tue Apr 14 13:25:43 CEST 2020

Am 14.04.2020 um 01:43 schrieb Skulski, Wojciech:

> I associate "undefined" with "Indeterminate", like in quantum
> mechanics. It means that the bit pattern would fluctuate and be
> different from case to case. The "unspecified" would be
> deterministic. Maybe I am reading too much. Maybe these two terms
> mean the same.

I think neither term says anything about whether the value is
deterministic. undefined means "nasal demons" all the time, and
unspecified (for me) means that implementations can specify it so it is
only "nasal demons" in some implementations.

The value of uninitialized local variables in Oberon is unspecified.
There can be implementations that initialize them with zero, and other
implementations can use whatever happens to be in the memory cell the
variable points to.

In the second case, the value is different between method invocations,
assuming that the method is called from different places with different
memory layout, so (from the view of the method) it is nondeterministic,
but when you look at the chip with a JTAG debugger you will see it is
perfectly deterministic (unlike some open wires or faulty transistors).

You can have similar behaviour with (floating-point) arithmetic, too,
where some (co-)processors have larger internal intermediate values in
its floating point registers than when you read the value and store it
again. Depending on compiler optimization (or even runtime optimization
by microcode) the resulting end values can change slightly; so they are
nondeterministic from the outside view, but still deterministic when you
look at the chip with a JTAG debugger.



More information about the Oberon mailing list