Oberon Report Update 2016-05-01

[cfbsoftware]

By allowing strings to be assigned to (variable parameter) open character arrays we introduce a new kind of run-time error which occurs when the length of the destination array is too small.

Character arrays and strings are a special case. The rules that apply to them do not apply to arrays in general.

Note that strings are effectively array initialisers and that array initialisers are not defined for arrays other than character arrays. Also the length of character arrays is determined by the position of the null byte that can only be determined at runtime whereas the length of arrays with base types other than CHAR can be determined at compile-time.

[cfbsoftware]

3. Open arrays can be assigned to arrays with the same base type.

If I understand it correctly, Wirth's own compiler only causes program abortion if the source array is longer than the destination array.

That is correct. In this exceptional case, the lengths of the arrays do not have to match, only the base types. The compiler implementer can decide what the runtime behaviour should be when the lengths are different.

[cfbsoftware]

The general rule is: An array may be assigned to an array of equal base type and equal length.

Only if the arrays have the same type.

That depends on the interpretation of same type. My understanding of the latest report and feedback from Wirth is that arrays are assignment-compatible if they are structurally equivalent - they don't have to conform to name-equivalence.

[augustk]

Note that strings are effectively array initialisers and that array initialisers are not defined for arrays other than character arrays. Also the length of character arrays is determined by the position of the null byte that can only be determined at runtime whereas the length of arrays with base types other than CHAR can be determined at compile-time.

Indeed. To avoid confusion I think character sequence is a good name for a string stored in a character array. The length of a character sequence is smaller than the length of the character array it is stored in.

[augustk]

3. Open arrays can be assigned to arrays with the same base type.

If I understand it correctly, Wirth's own compiler only causes program abortion if the source array is longer than the destination array.

That is correct. In this exceptional case, the lengths of the arrays do not have to match, only the base types. The compiler implementer can decide what the runtime behaviour should be when the lengths are different.

So, since the behavior is undefined, the program should always assert that the lengths are equal before the assignment.

[cfbsoftware]

So, since the behavior is undefined, the program should always assert that the lengths are equal before the assignment.

Not necessarily. Compiler implementers are free to define these sorts of implementation-specific details in the documentation they provide with their compiler. This might be in the form of a tutorial with examples or a reference document e.g. the Astrobe Programmer's Guide. You should be able to rely on that information to determine the best solution for each particular problem.

[augustk]

The general rule is: An array may be assigned to an array of equal base type and equal length.

Only if the arrays have the same type.

That depends on the interpretation of same type. My understanding of the latest report and feedback from Wirth is that arrays are assignment-compatible if they are structurally equivalent - they don't have to conform to name-equivalence.

So this module is valid:

Code: Select all

MODULE M;

	TYPE
		String = ARRAY 32 OF CHAR;

	VAR
		s: String;
		s1: ARRAY 32 OF CHAR;
		
BEGIN
	s := "test";
	s1 := s
END M.

How can we come to that conclusion from reading the Oberon report?

[cfbsoftware]

So this module is valid:

Yes - I believe so. Wirth's RISC5 compiler allows it although that is not necessarily conclusive as he has implemented some language extensions not included in the Report.

How can we come to that conclusion from reading the Oberon report?

It is not obvious to me. You could if you interpreted same type as referring to structure equivalence instead of (e.g. Pascal's) name equivalence. That is not clearly defined in the report as far as I can see. However, structure equivalence is explicitly ruled out in the case of records, the other type of structure, by the exceptional assignment rule:

3. In the case of records, the type of the source must be an extension of the type of the destination.

A good explanation of the difference between the two forms of type equivalence is here:

https://people.cs.clemson.edu/~turner/c ... ch5_3.html

Note that the following two Oberon examples are now also valid according to the 3.5.2016 Version of the report. They might provide some food for thought?

Code: Select all

MODULE M;

   TYPE
      String = ARRAY 32 OF CHAR;
      NewString = String;

   VAR
      s: String;
      s1: NewString;
      
BEGIN
   s := "test";
   s1 := s
END M.

Code: Select all

MODULE M;

   TYPE
      String = ARRAY 32 OF CHAR;

   VAR
      s: String;
      s1: ARRAY 32 OF CHAR;

PROCEDURE P(s: ARRAY OF CHAR);
BEGIN
  s1 := s
END P;
      
BEGIN
   s := "test";
   P(s)
END M.

[augustk]

Note that the following two Oberon examples are now also valid according to the 3.5.2016 Version of the report.

Code: Select all

MODULE M;

   TYPE
      String = ARRAY 32 OF CHAR;

   VAR
      s: String;
      s1: ARRAY 32 OF CHAR;

PROCEDURE P(s: ARRAY OF CHAR);
BEGIN
  s1 := s
END P;
      
BEGIN
   s := "test";
   P(s)
END M.

The compiler implementer can decide what the runtime behaviour should be when the lengths are different.

If the compiler implementor can decide what the runtime behavior should be when the lengths are different, your "valid" example above is not guaranteed to run successfully. Did you mean "when the source is longer than the target"? I'm confused.

[cfbsoftware]

If the compiler implementor can decide what the runtime behavior should be when the lengths are different, your "valid" example above is not guaranteed to run successfully. Did you mean "when the source is longer than the target"? I'm confused.

No. It runs 'successfully' if it runs as intended, in a predictable way, as documented by the implementer - even if that results in the program terminating with an error message. One possible alternative implementation would be to silently truncate the result if the target is shorter than the source. Another might be to not copy anything at all and report the problem in an error log. Another might implement some form of exception handling with error recovery etc. etc.

If the programmer has any reasonable doubts about the consequences of using a construct in a particular way then he should not use it in that way.