"J. David Bryan" wrote:
On 17 Oct 2001, at 13:32, Frank Heckenbach wrote:
I was going to say that it can input/output via files etc., but given that all files that are not mentioned in the header are internal and their contents will be gone after the program terminates, and ISO-7185 doesn't provide any other way of doing I/O, it seems indeed that such a program couldn't do much more than wasting some CPU time.
That is not strictly true. Consider that a program-level variable might be bound by the linker to a memory-mapped I/O address (specifically, in an embedded-controller application, where file I/O is less likely to be the means of affecting the environment).
Another application is where the program itself is the side-effect, i.e., test cases that are expected to trip syntax errors (and therefore are never expected to be executed).
So, should we leave the warning (because it's pointless to write such a program)?
I do not believe so.
Warnings are appropriate for situations where the outcome may be unexpected. For example, consider two nested blocks, each containing variable declarations, and the inner variable name differs from the outer variable name only in case (e.g., "var CogEntry" and "var CoGentry"). In this case, the programmer might be surprised when the inner variable hides the outer one (due to Pascal's case insensitivity).
However, for omitted program parameters, either the program will be legal, or it will be illegal, depending on the presence of implicit uses of "input" and "output" later in the program. Regardless, there will be nothing surprising. In the former case, there can be no implicit I/O calls; in the latter case, there must be an error diagnostic during compilation.
Warning the programmer of something that is clearly intentional is not warranted.
I don't consider such hiding an error. The fact that an outer block has an unaccessible identifier is a fact of life in such a case, and comes directly from scope rules. I have often done it deliberately, in order to protect the (relatively) global variable.
I am continuously having to replace the address in replies. Once more, what is the consensus on having a "reply-to: gpc@gnu.de" header in the lists output?