Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ncar!noao!stsci!siegel From: siegel@stsci.EDU (Howard Siegel) Newsgroups: comp.lang.fortran Subject: Re: Message-ID: <1646@stsci.edu> Date: 2 Aug 90 04:16:35 GMT References: <2009@key.COM> <58237@lanl.gov> <3250.26b00265@mccall.com> Reply-To: siegel@stsci.edu (Howard Siegel) Distribution: usa Organization: TRW, c/o Space Telescope Science Institute, Baltimore Md. Lines: 36 In <3250.26b00265@mccall.com>, tp@mccall.com writes: >i.e. check the range of a subscript and use it if it is valid, in the same >conditional. The corresponding FORTRAN > > if(a.ge.1.and.x(a).eq.0)... > >is NOT safe, because the subscript may be used before its validity is >checked, since FORTRAN does not specify the order of evaluation, nor >guarantee that all parts won't be evaluated. > [...stuff deleted...] >In this case the C code is much cleaner, since it does what the average >user would expect, whereas it is not obvious to the novice user why the >FORTRAN example won't work (this precise usage is a VERY common novice >programming error). Oh So True! It's not just a novice error in that an experienced FORTRAN coder (!) may not be familiar enough with the formal definition of the language. We had a case like this that had been working correctly for over a year before the sh*t hit the fan. Since VMS 4.something days the FORTRAN compiler had been observing left to right evaluation order and things worked. Things stopped working (actually all hell broke loose, we started getting access violations) at about VMS V5.2. Looking into the machine code the compiler produced showed that the right side of the expression was being evaluated first, before the left side check for the proper conditions. We know better now! ==-->> Standard disclaimers applied. Your mileage will vary! <<--== Howard Siegel (301) 338-4418 TRW c/o Space Telescope Science Institute Baltimore, MD 21218 Internet: siegel@stsci.edu SPAN: STOSC::SIEGEL uucp: {arizona,decvax,hao}!noao!stsci!siegel