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,FREEMAIL_FROM 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!news3.google.com!news.glorb.com!wn14feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!b680011b!not-for-mail From: Dick Hendrickson User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.fortran Subject: Re: Ada vs Fortran for scientific applications References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 71a774372d2e60da07b74408a0d9d39f X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1148490775 71a774372d2e60da07b74408a0d9d39f (Wed, 24 May 2006 17:12:55 GMT) NNTP-Posting-Date: Wed, 24 May 2006 17:12:55 GMT Organization: AT&T Worldnet Date: Wed, 24 May 2006 17:12:55 GMT Xref: g2news2.google.com comp.lang.ada:4418 comp.lang.fortran:10207 Date: 2006-05-24T17:12:55+00:00 List-Id: Dr. Adrian Wrigley wrote: > On Wed, 24 May 2006 15:19:23 +0000, Dick Hendrickson wrote: > > >> >>robin wrote: >> >>>"Dick Hendrickson" wrote in message >>>news:PkHcg.90575$Fs1.7198@bgtnsc05-news.ops.worldnet.att.net... >>> >>> >>>>Ada's is surely better. Knowing that a subscript has to be >>>>in range, because it's checked when a value is assigned to >>>>the subscript variable, has to be more efficient than what >>>>Fortran can do. In general, Fortran has to check the value >>>>of the subscripts on every array reference. >>> >>> >>>It can do this only if it is a compiler option. >>>It is not a feature the language. >> >>There's a ambiguous "it" in those sentences. ;) >> >>But, if "it" refers to Fortran, subscript bounds rules >>ARE a feature of the language. You are NEVER allowed to >>execute an out-of-bounds array reference in a Fortran >>program. > > ... > > So what does the standard say must happen if you attempt > such an access? Can a program fail unpredictably under > such (rather common!) circumstances - as routinely happens > in C and C++, sometimes at great cost? The Fortran standard says nothing at all about what must happen for most run-time errors. There is a requirement that a compiler be able to diagnose syntax-like errors at compile time. There is also a requirement that some (unspecified) I/O errors and some memory management errors be checked for at run time. The job will abort unless the program uses one of the error detection methods. But for things like subscript bounds errors, or subroutine argument mismatches, the standard doesn't impose anything on the compiler. In general, the standard imposes restrictions on standard conforming programs, not on the compiler. This allows compilers to extend the standard in "useful" ways. Technically, a standard conforming program is not allowed to use these extensions, but many do ;). Most compilers implement a command line option to do enhanced syntax checking and report use of extensions. Subscript bounds errors usually go unchecked and do whatever they do. They're really fun to debug because adding a PRINT statement usually moves the effect to some other part of the program. This isn't Fortran's greatest strength ;) . It was a compromise between safety and speed. The other big problem with [old] Fortran programs was messing up the argument list in a procedure call. Separate compilation made this a lot easier to do. The Fortran 90 addition of MODULES essenially closes this hole. Most procedure interfaces now can be explicit and the compiler must check for calling consistency. It's harder to shoot yourself in the foot now, but people can still lie to the compiler. Dick Hendrickson > -- > Adrian >