Gary Scott sbcglobal.net> wrote:

The standard doesn't and can't guarantee anything about that. That's
true of all versions, and for that matter to a certain extent of all
languages.

"Crashes" can happen for many reasons, but most of them boil down to one
of:

1. Hardware broke. Sorry, but if the machine catches on fire, the
Fortran standard isn't going to guarantee that Fortran programs still
behave in any kind of desirable way. Same for any other language. Now
just possibly, you might have something like an interupt to let you know
"machine on fire; you don't have long; clean up what you can", but the
standard doesn't guarantee that.

2. Compiler broke. Which is to say that the compiler isn't conforming to
the standard in some sense. Again, I'm afraid the standard doesn't cover
how compilers have to act when they fail to conform to the standard.
There are some circularity problems with that.

From a standards perspective, both of the above are actually the same.
In both cases the "processor" failed to conform to the standard. The
distinction between whetherthe failure is because of hardware or
software isn't in the Fortran standard.

3. User error. That is to say code that is nonstandard. Though I list
this 3rd, it is, of course, the most common category of reasons for
programs ti crash. I just put the previous 2 first because they were so
obvious. The kinds of nonstanadrd code that compilers are required to be
able to catch are pretty much all things that can be diagnosed at
compile time. There aren't any run-time error diagnostic requirements
that I can think of (but see 4 below). A "nice" system might be able to
catch some cases of this, but that's basically up to the system, which
is to say it is a quality of implementation issue. You aren't going to
be able to get anything that guarantees detection and useful response to
all of them - not in Fortran anyway. There is too large a variety, some
of which would be impractical to recover from. Suppose, for example,
that out-of-bounds array accesses had messed up the stack or other
critical bits of memory; you aren't likely to be able to do much useful
after that, including that it could have well mesed up things critical
to the error handling code (either yours or the systems). Now maybe
you've got run-time bounds error checking turned on so that this one
shouldn't happen, but that's back to a quality of implementation issue
rather than anything guaranteed in the standard. And out-of-bounds isn't
the only way to get memory messed up.

4. Things that aren't strictly speaking Fortran errors. These are your
best chance, but then the category is limited. Your code could detect a
problem and want to shut down. But that counts as a "normal" termination
from the perspective of the standard.