Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!i.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!ags
From: ags@s.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.pascal
Subject: Re: Control variables in FOR loops
Message-ID: <3695@s.cc.purdue.edu>
Date: 29 Dec 88 15:24:40 GMT
References: <1439@csuna.UUCP> <45@csd4.milw.wisc.edu> <1771@buengc.BU.EDU> <3693@s.cc.purdue.edu> <1804@buengc.BU.EDU> <1806@buengc.BU.EDU>
Reply-To: ags@s.cc.purdue.edu (Dave Seaman)
Organization: Purdue University
Lines: 34


 [quoting my earlier statement]
>>Not so.  The compiler writer is free to do whatever he likes, provided the
>>accompanying documentation describes the types of errors that are not
>>reported by the compiler.

In article <1806@buengc.BU.EDU> art@buengc.bu.edu (A. R. Thompson) 
	[actually Jim Miner] writes:
>In fact, the compiler writer is NOT "free to do whatever he likes" if she
>is writing a standards-conforming compiler.  Most of the restrictions under
>discussion are not "errors" (as defined in the standard), and thus a
>conforming processor (compiler) MUST detect violations of those
>restrictions.  It is only those restrictions explicitly defined by the
>standard as "errors" or "implementation-dependent" for which detection is
>optional.

The context of my earlier statement has been lost.  We were discussing
programs that make use of the control variable of a FOR loop after a normal
exit.

The standard says that such a control variable "becomes undefined" upon
loop termination.

The standard also says that "it is an error" for an expression to reference
an undefined variable.

The standard further says that errors need not be reported, provided the
accompanying documentation points out that fact.

Therefore, I stand by my original statement.

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu