Hi,

Just to note:  some compilers allow a compile-time flag to be
set that allows automatics larger than a specified size to
be allocated on the heap, rather than the stack.  But still,
the available storage can be exceeded by the request, and
the syntax of automatics does not allow checking and recovery
in case of failure.

In practice, this means that automatics have to be used only
for small arrays, at least in commercial codes.  It's different
for codes that are only to be used in-house, and not for
production purposes on a large variety of inputs and platforms.

I converted a large molecular-mechanics app to F90 some years
ago.  Let's just say that the convenience of automatics
was quickly outweighed by the problems that have been mentioned
in this email discussion.

I ended up doing the following:

1.  Using ALLOCATABLEs instead of automatics for large local arrays.
    This has been improved in F95 because the system will 
    do the DEALLOCATEs for you;  unfortunately, we didn't have F95
    back then, so we did the DEALLOCATEs ourselves.

2.  Inserted POSIX calls to raise the stacksize limits to whatever
    the largest available user limit is on the current machine.
    (Someone said something about an 8K stack limit in Linux;
    maybe I understood incorrectly, but this isn't in place on
    my RH 7.1 box.)

3.  Put in a complicated SEGV handler that tries to figure
    out heuristically whether the SEGV was probably a stack
    overflow -- in which case there's a good guess it was due
    to failure of automatic allocation.  This involved figuring
    out, in the handler, which direction the stack grows, and 
    where the heap is in relation to the stack, and seeing whether
    the relative position of the offending address (the one that
    triggered the SEGV) is one that could have been reached by
    a stack overflow.  Unfortunately, a random stray mem. ref.
    could also hit the same location, so it's just a guess.
    But for commercial code, you sort of need something like
    this, because it's tough to figure out whether the report
    of a SEGV coming in from an end user is a programming bug
    or a limitation of the environment.  This handler also
    used POSIX calls.

I love the syntax of automatics, but for them to really
be useful, there has to be a way the programmer can reliably
detect, at run time, the failure of an automatic to be
allocated, and to react to the condition as he sees fit.
Example:  print out an error message explaining the
problem, and suggest the user run with a larger stacksize.
This can't even be done now.

Just as a note, C now has "variable length arrays", which in
some contexts are precisely like Fortran automatics.  The 
problems are also identical.

-P.

On Fri, 7 Dec 2001, Anuchit Aromsawa wrote:

> Klaus Ramstöck wrote :
> I am amazed nobody has yet suggested to not use automatic arrays
> but rather allocate.
> ...........
> Arrays allocated this way are *NOT* located on the stack, which
> means this also avoids having to change the kernel.
> 
>  Klaus
>       I would like to thanks for your suggestion. I forgot  array allocation method.
> This may allow a huge size of array. Is allocated arrays stored in  heap store
> space?Is the heap storage space ulimited? If no, heap overflow could happen.
> This means that the "memory overflow" is unavoidable.
> Best Regards,
> anuchit
> 

-- 
  Peter S. Shenkin                      Schrodinger, Inc.
  VP, Software Development              120 W. 45th St.
  646 366 9555 x111 Tel                 New York, NY 10036
  646 366 9550 FAX                      [log in to unmask]
                                        http://www.schrodinger.com