Waldek Hebisch wrote:
I noticed that the following FPC code (claimed to be BP compatible) is not accepted by GPC:
function b:string; begin b[1] := ' ' end;
Similarely FPC accepts:
type a = record i, j : integer end; function b(i, j: integer) : a; begin b.i := i; b.j := j end;
I do not know if we want to implement that feature, but (assuming it is really accepted by BP) we should list it as known incompatiblity.
BP really accepts the first case (not the second one because it doesn't allow record result types, but if it did, it presumably might accept the second case too). Ouch!
It seems like BP does context-dependent parsing, treating the function-identifier differently in "lvalues" and "rvalues". The problem (besides being a rather strange thing in itself) it that it seems to be done wrongly. The `^' suffix operator (pointer dereference) can make an lvalue from an rvalue.
In particular, AFAICS in the following program, the `f' in `f^ := 3' must be a recursive call (yielding b), so b^ must be set to 3, and the program must say `1 3'.
BP, however, seems to think `f' is an lvalue before it sees the `^', so it sets the current function-result (which is a), dereferenced, to 3, and says `3 2'.
So, in contrast to the examples above, this is not an extension (i.e., some behaviour for a case otherwise invalid), but at least another incompatibility (if not to say, a violation of Pascal semantics) for a correct Pascal program, so I'm not sure if the whole thing is a bug or just a buggy feature.
program Foo (Output);
type PInteger = ^Integer;
var Called: Boolean; a, b, c: PInteger;
function f: PInteger; begin if Called then f := b else begin Called := True; f := a; f^ := 3 end end;
begin Called := False; New (a); a^ := 1; New (b); b^ := 2; c := f; WriteLn (a^, ' ', b^) end.
Frank