Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!boise.Eng.Sun.COM!wsb
From: wsb@boise.Eng.Sun.COM (Walt Brainerd)
Newsgroups: comp.lang.fortran
Subject: Re: Side effects in boolean expressions
Message-ID: <140799@sun.Eng.Sun.COM>
Date: 16 Aug 90 20:45:53 GMT
References: <2022@key.COM> <59110@lanl.gov> <2041@key.COM> <2047@key.COM>
Sender: news@sun.Eng.Sun.COM
Lines: 35

In article <2047@key.COM>, sjc@key.COM (Steve Correll) writes:
> In article <140684@sun.Eng.Sun.COM>, wsb@boise.Eng.Sun.COM (Walt Brainerd) writes:
> > In article <2041@key.COM>, sjc@key.COM (Steve Correll) writes:
> > > ... the C code is legal and its behavior predictable; the Fortran is neither:
                ^^^^^^^^^^^^^
> > > 	if ((x < 0.0) || (sqrt(x) < 10.0)) ...
> > > 	IF ((X .LT. 0.) .OR. (SQRT(X) .LT. 10.0)) ...
> > > 
> > The Fortran code certainly is legal...
> 
> I believe that a program which could cause the translator to invoke SQRT with
> a negative argument fails to conform to the Fortran 77 standard, because
> section 13.10.1, page 15-28 of the X3.9-1978 says:
> 
>    Square Root: The value of the argument of SQRT and DSQRT must be greater
>    than or equal to zero.
> -- 
> ....{sun,pyramid}!pacbell!key!sjc 				Steve Correll

Yes, good point.  By "code being legal", of course, I was thinking
of it being syntactically correct.  Executing it with negative X
is not legal, as pointed out.

The moral is that in C you can write these 2 tests in one line
and in Fortran it must be done with nested IFs, but Fortran allows
optimization of other similar expressions that do not have the property
that they must be done in two lines to make sure everything is OK.
Seems to me like the Fortran choice is "in the spirit of Fortran"
in that it allows for better optimization and puts a little more
burden on the programmer to get it right.
--
Walt Brainerd        Sun Microsystems, Inc.
wsb@eng.sun.com      MS MTV 5-40
                     Mountain View, CA 94043
                     415/336-5991