Hi,

I have a question about the validity of a construction that is
frequently used e.g. in the Numerical Recipes in FORTRAN 77, but that I
suspect to be the cause of segmentation faults in some cases. But before
 modifying all my source codes I would like to know whether this is
really a dangerous construction or not (and the reason for the errors is
something else).

Consider a simple array routine, for example the sum of squares of an array:

	SUBROUTINE sqrsum(n,a,o)
	INTEGER n,i
	DOUBLE PRECISION a(n),o
	o=0.d0
	DO i=1,n
	   o=o+a(i)**2
	END DO
	RETURN
	END

Normally you would declare a like this

	DOUBLE PRECISION a(100000)

or
	INTEGER n,nmax
	PARAMETER (nmax=100000)
	DOUBLE PRECISION a(nmax)

or so, i.e. using a constant. My question is simply: Is the upper way of
array dimensioning valid (at least in g77) or is it a "dirty hack" that
will work most times but may fail with segmentation faults, and
therefore cannot be recommended?

I know that the best way would be to post a minimal example, but I
suspect that the problem only occurs in more complex programs like the
one I have trouble with.

Ingo

Ingo Thies wrote:
> Hi,
> 
> I have a question about the validity of a construction that is
> frequently used e.g. in the Numerical Recipes in FORTRAN 77, but that I
> suspect to be the cause of segmentation faults in some cases. But before
>  modifying all my source codes I would like to know whether this is
> really a dangerous construction or not (and the reason for the errors is
> something else).
> 
> Consider a simple array routine, for example the sum of squares of an array:
> 
> 	SUBROUTINE sqrsum(n,a,o)
> 	INTEGER n,i
> 	DOUBLE PRECISION a(n),o
> 	o=0.d0
> 	DO i=1,n
> 	   o=o+a(i)**2
> 	END DO
> 	RETURN
> 	END
> 
> Normally you would declare a like this
> 
> 	DOUBLE PRECISION a(100000)
> 
> or
> 	INTEGER n,nmax
> 	PARAMETER (nmax=100000)
> 	DOUBLE PRECISION a(nmax)
> 
> or so, i.e. using a constant. My question is simply: Is the upper way of
> array dimensioning valid (at least in g77) or is it a "dirty hack" that
> will work most times but may fail with segmentation faults, and
> therefore cannot be recommended?
> 

In f66 and f77, the first version was called adjustable dimension.  It 
remains valid after f90, although the terminology changed, and perhaps 
is not well explained in all texts.
As the memory region has to be declared in the calling subroutine, there 
is no way to check for bounds violations at compile time, with separate 
compilation.  Most compilers (even g77) have optional checks for this, 
typically at run time.  f90 gives you additional options, including some 
which don't involve special time-consuming run-time options for bounds 
checks.

On Jul 6, 10:08 am, Ingo Thies <ingo.th...@gmx.de> wrote:

>         SUBROUTINE sqrsum(n,a,o)
>         INTEGER n,i
>         DOUBLE PRECISION a(n),o

> or so, i.e. using a constant. My question is simply: Is the upper way of
> array dimensioning valid (at least in g77) or is it a "dirty hack" that
> will work most times but may fail with segmentation faults, and
> therefore cannot be recommended?

This is a standard Fortran 77 feature called "adjustable array".  The
upper bound for the array A is taken from the integer argument N on
routine entry. It's perfectly fine.

Steve

Steve Lionel wrote:

> This is a standard Fortran 77 feature called "adjustable array".  The
> upper bound for the array A is taken from the integer argument N on
> routine entry. It's perfectly fine.

A thanks. This means that there is another error. Meanwhile I probably
have found it, and as I guessed, it was due to the complexity of the
program. In particulac, n has been initialized in the first call of the
problem but not saved for the following calls of the routine that calls
the crashed subroutine.

BTW I remember that there is another way of adjustable arrays using a(*)
or something like that. Is this also valid?

Ingo

Ingo Thies wrote:
| Steve Lionel wrote:
| 
|| This is a standard Fortran 77 feature called "adjustable array".  The
|| upper bound for the array A is taken from the integer argument N on
|| routine entry. It's perfectly fine.
| 
| A thanks. This means that there is another error. Meanwhile I probably
| have found it, and as I guessed, it was due to the complexity of the
| program. In particulac, n has been initialized in the first call of the
| problem but not saved for the following calls of the routine that calls
| the crashed subroutine.
| 
| BTW I remember that there is another way of adjustable arrays using a(*)
| or something like that. Is this also valid?

That form is called "assumed-size" arrays, and it's also valid since F77.
While most compilers implement the two in an identical manner, the 
difference comes for debugging and bounds-checking purposes. With
the "adjustable" arrays, the compiler has the possibility to check
whether the bounds are achieved (and debuggers also tend to handle
them in a more user-friendly manner). There are also some differences
pertaining F90 array operations, but they're tangential to the matter.

Of course, if the actual argument corresponding with N in the 
calling routine is wrong (denoting more elements than the actual
array size), things will go wrong with adjustable arrays as well.

-- 
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

On Jul 6, 11:29 am, "Jugoslav Dujic" <jdu...@yahoo.com> wrote:
> Ingo Thies wrote:
> | BTW I remember that there is another way of adjustable arrays using a(*)
> | or something like that. Is this also valid?
>
> That form is called "assumed-size" arrays, and it's also valid since F77.
> While most compilers implement the two in an identical manner, the
> difference comes for debugging and bounds-checking purposes.

Adjustable and assumed-size arrays are not typically implemented the
same.  Adjustable arrays can have variables for any of the bounds,
where assumed-size allows the * on only the last upper bound.  Also,
adjustable arrays are allowed to be used whole in I/O statements,
since the size is known, whereas assumed-size arrays are not.

While we're talking about assumed-size - in F66 it was common to
dimension a dummy argument array (1) when you didn't know the size.
In F77 you could use (*) for this, but many compilers, even today,
make a special case for (1) and disable bounds checking for (1).

Steve

Steve Lionel wrote:

> On Jul 6, 10:08 am, Ingo Thies <ingo.th...@gmx.de> wrote:

>>        SUBROUTINE sqrsum(n,a,o)
>>        INTEGER n,i
>>        DOUBLE PRECISION a(n),o

>>or so, i.e. using a constant. My question is simply: Is the upper way of
>>array dimensioning valid (at least in g77) or is it a "dirty hack" that
>>will work most times but may fail with segmentation faults, and
>>therefore cannot be recommended?

> This is a standard Fortran 77 feature called "adjustable array".  The
> upper bound for the array A is taken from the integer argument N on
> routine entry. It's perfectly fine.

Adjustable arrays in subroutines like this go back to Fortran 66.

The (*) dimension for 1D arrays, or for the last subscript of
higher dimension arrays, came in with Fortran 77.

-- glen