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!newsgate.cistron.nl!xs4all!news2.euro.net!sn-ams-06!sn-xt-ams-03!sn-ams!sn-feed-ams-01!sn-post-ams-01!sn-post-sjc-01!supernews.com!news.supernews.com!nospam From: nospam@see.signature (Richard Maine) Newsgroups: comp.lang.ada,comp.lang.fortran Subject: Re: Bounds Check Overhead Date: Fri, 26 May 2006 11:24:42 -0700 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <1hfxy4r.1sv2j76l6cgg1N%nospam@see.signature> References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> <6H9dg.10258$S7.9150@news-server.bigpond.net.au> <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature> <4475DA61.3080001@comcast.net> <44762F55.4050106@cits1.stanford.edu> <87hd3d1472.fsf@ludovic-brenta.org> <1hfxsjh.t88mchrssv9cN%nospam@see.signature> User-Agent: MacSOUP/2.7 (Mac OS X version 10.4.4) X-Complaints-To: abuse@supernews.com Xref: g2news2.google.com comp.lang.ada:4503 comp.lang.fortran:10302 Date: 2006-05-26T11:24:42-07:00 List-Id: Nasser Abbasi wrote: > > > I am not sure if there is supposed to compiler flag to enforce this or not, I said > Compilers are not required to enforce that rule, (In context, I meant Fortran compilers, as I do in all cases below.) In terms of the standard, that is basically all there is to say. As I tried to elaborate, almost all compilers do enforce simpe cases. I don't know of a compiler that doesn't. However, that has nothing to do with any requirement of the standard. The standard has nothing at all to say about compiler switches in any context. That is not a concept defined by the standard. > so I did this very simple test, No, this is not a simple test. This is one of the complicated cases. The code is short, but that doesn't necessarily mean simple to diagnose. This one is hard to test. See my previous comments about separate compilation. They are extremely relevent - indeed central here. > PROGRAM MAIN > > DO I=1,10 > CALL foo(I) > PRINT *,I > END DO > > END PROGRAM This is a perfectly valid main program, by the definition of the standard. In particular, it could be part of a valid entire program, when combined with an appropriate subroutine foo. > SUBROUTINE foo(I) > I=I+1 > END SUBROUTINE And this is a perfectly valid subroutine, when combined with an appropriate main program calling it. Although the two parts are separately valid, they don't "fit" together. It is only when you look at them together that they become invalid. This is a "traditional" codong style with an external subprogram, which might be compiled completely separately, the compiler having no knowledge of the subroutine when it is compiling the main program, and vise versa. *SOME* (definitely not all) compilers might catch this in some cases (such as when it is all in one source file, but "source file" is another concept not even defined in the Fortran standard). You could make this even harder to test by having the subroutine read some input and use that input to decide whether or not to increment the variable. In that case, the legality would depend on the input data. > I did the same in Ada: No you didn't do the same. I don't know whether g95 would happen to catch it if you did make the Fortran code comparable. I don't particularly care either. I know what the requirements of the Fortran standard are here - the compiler is not required to catch it, but some compilers might. I'm also not particularly interested in pursuing this line at all, I am aware that the Ada standard has stronger requirements in this area. I don't really need test cases to illustrate that. The only reason I'm posting this part is to point out that your test programs are not, in fact, very close to "the same". You Ada procedure foo is defined inside the main program, not outside of it. The comparable thing in Fortran would be an internal procedure, not an external procedure. Internal procedures are not compiled separately. Therefore, the odds of catching things like this in an internal procedure are far better. It still is not guaranteed. I might have seen some bugs resulting form uncaught errors in that situation. But the odds are at least better. > The above will not even be allowed to compile since Ada wants 'I' to be an > actual variable. I don't know Ada well enough to interpret this precisely. It has been far too long since I did anything in Ada (about 15 years). But if I am interpreting your statement there correctly, I'd say that a fundamental difference here is that in Fortran, a look index *IS* an actual variable, just like any other. There are restrictions on how you may use it (some of them hard for the compiler to test, as mentioned above), but it fundamentally is a variable. This has good points and bad points. I'm not feeling like arguing such things. I'll stick to describing the factual matters. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain