J. David Bryan wrote:
On 18 Oct 2001, at 1:08, Frank Heckenbach wrote:
Is this allowed...
I don't believe that you will find anything in the standard that mandates that variables be mapped specifically to memory locations and not, e.g., to I/O devices. Such a mapping surely is the function of the external environment and therefore won't appear in the standard.
So, the following program would be allowed to output 0, according to the standard (because i might be mapped to an I/O address that happens to always yield 0)? I strongly doubt it? If anything, I can only imagine that a program parameter mentioning of i could warrant such a behaviour.
program Foo (Output);
var i: Integer;
begin i := 42; WriteLn (i) end.
My point simply is that there may be mechanisms for a conforming program without program parameters to affect the external environment. Assuming that a syntactically correct Pascal program cannot have any useful effect and therefore should be rejected by GPC is unwarranted.
Agreed.
...(since it might change the meaning of the program)?
ISO 7185, section 5.2, "Compliance, Programs" says, in part:
"The requirements for conforming programs and compliant processors do not require that the results produced by a conforming program are always the same when processed by a compliant processor."
(...though this is a note and therefore not normative.)
Yes, but some things (like that the program above should write 42, possibly preceded by a number of spaces) are guaranteed, I think.
ISO 7185, 6.10 says: "The binding of the variables denoted by the program-parameters....
This describes the requirements for any such variables mentioned in the program-parameter-list but does not say that any variable that might be bound to an external entity by the environment *must* be mentioned there (i.e., this section defines one such binding method but does not prohibit other, unspecified methods that might be present in the external environment).
This would, in the utmost consequence, mean that any valid Pascal program can do anything, and the standard could be reduced to a syntax diagram.
...but I also gather that such variables that you talk about should be mentioned there...
I disagree, unless the standard has some explicit restriction on how such variables are allocated to physical storage by the external environment (I couldn't find such a restriction).
It's not mainly about the allocation on physical storage (if a variable is allocated in a file, transparently read and written, that's probably ok), but about (intended) side-effects of seemingly "innocent" variables.
Perhaps we're arguing to no purpose here. Do you agree that GPC should not reject a syntactically legal program that doesn't specify a program- parameter-list? If so, then my argument is irrelevant to this point.
Yes.
Maybe a borderline-case of "meaningful". (Providing a compiler feature that only exists to be tested seems quite strange to me. ;-)
Then the whole GNU "autoconf" mechanism must seem strange to you! ;-)
I don't think it uses any shell, gcc or whatever features specifically developed for autoconf. -- I didn't mean writing a program only to test a compiler feature seems strange, but introducing a compiler feature that makes sense only for such programs would seem strange.
As another example, the GPC test suite should test to ensure that legal Pascal programs are processed correctly, but also that illegal Pascal programs are caught and reported, yes? In that case, a test program such as:
program casetest;
var mixedcase, MixedCase : integer;begin end.
exists to ensure that the Pascal compiler is case-insensitive (a syntax error is expected) and therefore would be meaningful without any program parameters. Requiring this program to have "(output)" in the program header would be pointless.
It was a warning only, anyway, just like the program might produce a warning about unused variables. The test should ignore these warnings (`-w' for GPC).
(By the way, gpc-20010924 does *not* catch this error!)
(dave1.pas)
Frank