AW: [Oberon] 0X enigma

Jörg Straube joerg.straube at
Fri Jul 2 02:49:11 MEST 2010

Hi Denis

Not all Oberon compilers generate the "enigma" you found.
E.g. Paco generates code where LEN(chars) = 1 in
both cases (0X and '')

But even the compiler you use generates code that
is totally legal. It's a question of optimization.


-----Ursprüngliche Nachricht-----
Von: oberon-bounces at
[mailto:oberon-bounces at] Im Auftrag von spir
Gesendet: Dienstag, 29. Juni 2010 14:09
An: Oberon
Betreff: [Oberon] 0X enigma


My in-progress custom Text type had a strange behaviour in case a text is
initialised with 0X (I rely on the fact that a character is automatically
converted to an ARRAY OF CHAR, which is the type of the formal parameter of
the method Text.init). Any other case works fine.
As a trial to elucidate the issue, I wrote the following test:

MODULE ___trial___;


	chars : ARRAY 4 OF CHAR;

	Out.LongInt(LEN(chars),0) ; Out.String(' : ') ;
	Out.String('|') ; Out.String(chars) ; Out.String('|') ;
	Out.Ln ;
END show;

	chars := 'abc' ; show(chars) ;
	show('abc') ;
	show('a') ;
	show(61X) ;
	show('') ;
	show(0X) ;
END ___trial___.
=== output ===
4 : |abc|
4 : |abc|
2 : |a|
2 : |a|
1 : ||
2 : ||

I thought and read that 0X is equivalent to ''. It is equivalent for output,
since 0X produces none per definition; but its internal representation is
not the same. This indeed fools my code (or rather my initial assumption):
the init method records an actual content size of 1.
Actually, this behaviour may be better, allowing the user to define a String
really containing a single char (or byte) that actually holds 0X.
But I would like to elucidate the enigma anyway.


vit esse estrany ?
Oberon at mailing list for ETH Oberon and related systems

More information about the Oberon mailing list