Was there a bug in Wirth's original Pascal compiler?

Question

It appears that both legacy Pascal compilers I have access to (for the BESM-6) contain a bug: they would happily produce code for

program test(output);(* may have to omit (output) depending on the platform *)
function f: integer; (* entering the function sets R2 as the frame pointer *)
begin f := 7 end;    (* assigning 7 to 3(R2) - the value return location *)
begin f := 11 end.   (* assigning 11 to 3(R2), where R2 has not been initialized yet *)

Both compilers were derivations from one CDC 6600 version or another, up to the data structures and the order of the subroutines. As the bug is in the machine-independent part, which logic would be transcribed unchanged, I suspect that it would exist in all Pascal implementations derived directly from the same CDC 6600 source by bootstrapping.

Could anyone please verify that on a CDC 6600 emulator, if one exists, or using a Pascal compiler known to be a port of the original?

JFYI:

Newer Pascal compilers written in C using YACC do error out on the test case above.

Free Pascal complains, on line 4, Error: Argument cannot be assigned to (why "Argument", though?).

UCB Pascal on BSD 2.11 is more lucid, saying function f found where variable required.

One other I could find online, Turbo Pascal, however, fails with some kind of an internal error: Error: can't cast from 70 to 76 ("11", line 4).

Answer 1

If the compilers you have were based on the P-series, then I believe that there was indeed a bug.

In the P-series compilers after P2, the destination of an assignment is determined by a routine named selector, which branches on the klass field of fcp, a variable that holds information about a relevant identifier. When the klass is func, i.e., when the identifier is the name of a function, P2 does this:

IF PFDECKIND = STANDARD THEN ERROR(150)
ELSE
  IF PFLEV = 0 THEN ERROR(150)   (*EXTERNAL FCT*)
  ELSE
    IF PFKIND = FORMAL THEN ERROR(151)
    ELSE
      BEGIN ACCESS := DRCT; VLEVEL := PFLEV + 1;
        DPLMT := 0   (*IMPL. RELAT. ADDR. OF FCT. RESULT*)
      END

There is an assumption here that an assignment to a function identifier will happen only within the function's body, but no explicit check. In P4, this bit of code was changed to

if pfdeckind = standard then
  begin error(150); typtr := nil end
else
  begin
    if pfkind = formal then error(151)
    else
      if (pflev+1<>level)or(fprocp<>fcp) then error(177);
      begin access := drct; vlevel := pflev + 1;
        dplmt := 0   (*impl. relat. addr. of fct. result*)
      end
  end

Here, pflev is a field of fcp, representing the level of nesting at which fcp was declared; level is a global variable holding the current depth of nesting; fprocp is a parameter of block, which is non-nil if the block is the body of a function or procedure. Thus the newly-added line ensures that we are (1) in the body of a function and (2) allowed to perform the assignment. Error 177 is new to P4, and means

You may only assign to the identifier of a function in the body of that function.

There are other early compilers whose source code survives, which were the progenitors of the P-series compilers; none of them, except for the 1984 version, seem to include the check for assignment validity.

---

You might have noticed the strange begin and end in the P4 excerpt. This was also pointed out by Pemberton and Daniels (the third item in the Notes section below). The effect is that code for the assignment is generated, even though it is erroneous; presumably there is an else missing.