From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,c4cb2c432feebd9d
X-Google-Thread: 1094ba,c4cb2c432feebd9d
X-Google-Attributes: gid103376,gid1094ba,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!news3.google.com!news.glorb.com!news.aset.psu.edu!news.cse.psu.edu!elk.ncren.net!scrotar.nss.udel.edu!not-for-mail
From: Rich Townsend <rhdt@barVOIDtol.udel.edu>
Newsgroups: comp.lang.ada,comp.lang.fortran
Subject: Re: Bounds Check Overhead
Date: Fri, 26 May 2006 10:52:23 -0400
Organization: University of Delaware
Message-ID: <e574mu$rrj$1@scrotar.nss.udel.edu>
References: <mubcg.13522$fb2.853@newssvr27.news.prodigy.net>
	<epcs4e.qb8.ln@hunter.axlog.fr>
 <tHkcg.6937$kR6.484@trnddc05>	<0ugu4e.4i7.ln@hunter.axlog.fr>
	<PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net>
	<To_cg.10095$S7.4017@news-server.bigpond.net.au>
	<%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net>
	<6H9dg.10258$S7.9150@news-server.bigpond.net.au>
	<XVadg.76594$_S7.45873@newssvr14.news.prodigy.com>
	<1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature>
	<pan.2006.05.25.12.11.52.919554@linuxchip.demon.co.uk.uk.uk>
	<4475DA61.3080001@comcast.net>
 <m2mzd569l9.fsf@grendel.local>	<44762F55.4050106@cits1.stanford.edu>
 <87hd3d1472.fsf@ludovic-brenta.org> <3cBdg.6255$oa3.2407@trnddc08>
 <SuEdg.167361$eR6.86840@bgtnsc04-news.ops.worldnet.att.net>
NNTP-Posting-Host: shayol.bartol.udel.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: scrotar.nss.udel.edu 1148655134 28531 128.175.14.63 (26 May 2006
 14:52:14 GMT)
X-Complaints-To: abuse@udel.edu
NNTP-Posting-Date: Fri, 26 May 2006 14:52:14 +0000 (UTC)
User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060417)
X-Accept-Language: en-us, en
In-Reply-To: <SuEdg.167361$eR6.86840@bgtnsc04-news.ops.worldnet.att.net>
Xref: g2news2.google.com comp.lang.ada:4493 comp.lang.fortran:10290
Date: 2006-05-26T10:52:23-04:00
List-Id: <comp.lang.ada>

Dick Hendrickson wrote:
> 
> 
> Dan Nagle wrote:
> 
>> Hello,
>>
>> Ludovic Brenta wrote:
>>
>> <snip>
>>
>>> And that's why Ada specifies that I cannot change inside the loop, and
>>> is undefined outside the loop; see ARM 5.5 (9, 10).
>>>
>>> You seem to imply that Fortran has a similar rule, but that compilers
>>> do not enforce that rule, and therefore have to perform range checking
>>> to enforce a non-existent language rule about array access.  I am
>>> confused.  Could you clarify?
>>
>>
>>
>> A loop index cannot be changed within the loop.
> 
> It's actually a stronger rule, or maybe Dan's statement
> could have been worded stronger.  The loop index can't
> be changed while the loop is executing.  This covers
> direct assignment in the loop and also in procedures
> called from within the loop.
>      Given something like
>      COMMON I
>      DO I = 1,10
>         call something (I)
>         call something_else()
>      enddo
> "something" is not allowed to change it's argument and
> neither "something" nor "something_else" is allowed to
> change the variable in common.  This prohibition flows
> down the entire call tree from these routines.  And that's
> why it's hard to check.

...although a lot of the constructs introduced in Fortran 90 help in checking -- 
in particular, if the called subroutines have INTENT() on their arguments, then 
its pretty cut-and-dry whether I will be modified or not. Having said that, 
things like host association can muddy the waters somewhat -- but at least you 
only have to go down one level to check if I is being modified.

cheers,

Rich