[comp.lang.fortran] max function in dim. stmt in sun f77 1.3.1

mclay@vato.ae.utexas.edu (Robert McLay) (02/06/91)

Under sun f77 v1.3.1 it now complains about the use of the max
function in an adjustable array dimension statement.  This use to work
in version 1.2 and before.

  Namely here is the code

        program junk
        integer a(10000)

        n = 0
        call abc (a(1),100,a(100),n)
        end
        subroutine abc(a,m,g,n)

        integer a(m),g(max(1,n))
        a(1) = 1
        return
        end


In the actual case n is sometimes zero and some time not.  This does work
on vax vms fortran and cray fortran.  What is surprising is that it
use to work in sun f77 v1.2.

I know that there are ways around it, but in the actual case this is
the best way to do it.

--

______________________________________________________________________________
Robert McLay                   | When you have a problem, put NO in front of
Manager CFD Lab                | it and you have:  NO PROBLEM.
Dept ASE-EM                    |
University of Texas at Austin  |           -- Eric Beckman's 2nd Law
                               |
mclay@wilbur.ae.utexas.edu     |

khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (02/06/91)

In article <MCLAY.91Feb5103005@vato.ae.utexas.edu> mclay@vato.ae.utexas.edu (Robert McLay) writes:

   Under sun f77 v1.3.1 it now complains about the use of the max
   function in an adjustable array dimension statement.  This use to work
   in version 1.2 and before.
...
	   integer a(m),g(max(1,n))

Page 5-2 of our favorite book (X3.9-1978)

...definition of an array declarator in progress...A dimenion bund
expression must not contain a function or array element reference....

So this is illegal (non-standard, to be a bit more precise). So why did
it work before ?

bugid 1021366 adjustable array declarations not checked (I'm
simplifying). There are also bugids for generating wrong code when the
expression evaluated to zero, etc. (since it was the last dimension,
it really didn't matter what was returned for most cases ... 0 was a
bad counter-example).

The fix (which made a bunch of folks happy) was to provide a bit
of testing to ensure sanity. The obvious way to construct such tests
is to follow the standard. 

Now, allowing certain functions is feasible (f90 committee time was
spent debating it extensively). But we just had a thread where a
poster argued that extensions are somewhat evil.... votes gents and
ladies? Should we allow this in a future version (too late for v1.4)?
Should it be tied to the -xl switch (act a bit more vaxlike)?

--
----------------------------------------------------------------
Keith H. Bierman    kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33			 | (415 336 2648)   
    Mountain View, CA 94043

3003jalp@ucsbuxa.ucsb.edu (Applied Magnetics) (02/07/91)

In article <KHB.91Feb5190439@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes:

>...
>	   integer a(m),g(max(1,n))

>votes gents and ladies? Should we allow this in a future version
>(too late for v1.4)?

If the expression can be evaluated at compile time, it should be allowed.

  --Pierre Asselin, R&D, Applied Magnetics Corp.  I speak for me.