On Thu, Dec 19, 2002 at 05:21:11AM +0100, Frank Heckenbach wrote:
Artur Zaroda wrote:
[...]
program az35(output); var output:file of real; begin writeln('failed') (* WRONG - output is not of type "text" *) end.
Is it not already an error to (re)declare `Output' as a variable?
`Output' is an identifier, not a keyword, so it may be redefined freely. But then it stops to be magic, i.e. it can't be used as an implicit file parameter of Write(Ln), it needs an explicit Rewrite, and (contrary to usual Pascal conventions for shadowing predefined identifiers) it mustn't occur in the program parameter list (see ISO 10206 6.12). Thus az35 is faulty for at least three separate reasons, which may be isolated as follows (Out1 fails in GPC, Out[23] work):
program Out1 (Output); (* FLAG --classic-pascal *)
var Output: Text; { WRONG - Output already used as program parameter }
begin end.
program Out2; (* FLAG --classic-pascal *)
var Output: Text;
begin WriteLn ('failed') { WRONG - missing file variable } end.
program Out3 (Output); (* FLAG --classic-pascal *)
var F: file of Char;
begin Rewrite (F); WriteLn (F); { WRONG - not a text file } WriteLn ('failed') end.
However, the following is allowed (and it works in GPC):
module Out4m; (* FLAG --extended-pascal *)
export Out4i = (OK);
procedure OK;
end;
import StandardOutput;
procedure OK; begin WriteLn ('OK') end;
end.
program Out4; (* FLAG --extended-pascal *)
import Out4i;
var Output: Text;
begin Rewrite (Output); WriteLn (Output, 'failed'); OK end.
The following should also work, IIUC the rules in 6.11.4.2. (Currently it just crashes the compiler.)
program Out5; (* FLAG --extended-pascal *) import StandardOutput only (Output => Brecks);
begin WriteLn ('OK') end.
[~/pascal/test]% gpc -O2 -fextended-pascal out5.pas out5.pas:3: internal error: NeoprĂĄvnĂŹnĂ˝ pøĂstup do pamĂŹti (SIGSEGV) Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu-pascal.de/todo.html for instructions.
On Mon, Dec 16, 2002 at 08:15:34AM +0100, Artur Zaroda wrote:
program az45(output); var x:boolean; function f:integer; begin f:=1; x:=true end; begin x:=false; if 1 in [1,f] then if x then writeln('OK') else writeln('failed') end.
I don't think this should write 'OK'. The standard says:
6.8 Expressions
6.8.1 General
[...] The member-designator x, where x is an expression, shall denote the member that shall be the value of x. The member-designator x..y, where x and y are expressions, shall denote zero or more members that shall be the values of the base-type in the closed interval from the value of x to the value of y. The order of evaluation of the expressions of a member-designator shall be implementation-dependent. The order of evaluation of the member-designators of a set-constructor shall be implementation-dependent.
6.8.3 Operators
6.8.3.1 General
[...] A primary, a factor, a term, or a simple-expression shall be designated an operand. Except for the and_then and or_else operators, the order of evaluation of the operands of a dyadic operator shall be implementation-dependent.
NOTE -- This means, for example, that the operands may be evaluated in textual order, or in reverse order, or in parallel, or they may not both be evaluated.
3.5 Implementation-dependent
Possibly differing between processors and not necessarily defined for any particular processor.
IMHO this means that the compiler is allowed not to call `f' when evaluating `1 in [1,f]', if it doesn't want to.
An unrelated bug report: GPC fails to compile the program below.
program SchemaFunc (Output);
type Sch (I: Integer) = array [1 .. I] of Integer; S = Sch (13);
var A: S;
function G: S; begin G := A end;
begin A[7] := 42; if G[7] = 42 then WriteLn ('OK') else WriteLn ('failed') end.
[~/pascal/test]% gpc schfunc.pas schfunc.pas: In function `G': schfunc.pas:13: incompatible types in assignment schfunc.pas: In main program: schfunc.pas:18: subscripted object is not an array or string
Emil