(j3.2006) when does an error condition occur in executing EXECUTE_COMMAND_LINE
Fri Jan 16 14:25:13 EST 2009
Michael Ingrassia wrote:
>> My inclination is to intentionally
>> not specify what errors can or cannot be detected.
> Ok, but we can and should add value to the standard by making it possible
> for as many errors as possible to be error conditions, right?
> The distinction is that once an error occurs, all bets are off and the
> program can do anything; but the standard can prescribe what happens
> for error conditions (e.g., you lose the guarantee that something actually
> got allocated but if you set the STAT variable then execution does not
> terminate, etc.)
> Say you call EXECUTE_COMMAND_LINE and the command doesn't execute.
> The standard says it does, so you're in error territory and nothing else
> about your program execution is guaranteed by the standard. But if
> command not executing is an error condition, maybe CMDSTAT or EXITSTAT
> could be set and the program and processor could still be standard-conforming.
> I thought that's what we wanted, and if so I still think
> some of the language in the standard is not quite right.
> The standard shouldn't say "a command will be executed" -- that makes it an
> error if a command isn't executed whereas some OS's can do better (can detect
> some errors).
> The standard should say "unless an error condition occurs, a command will
> be executed" -- that permits (but does not require) an error condition to
> be detected if a command isn't executed.
I think that is what is implied. In many places in the standard, we say
'statement X does Y' when we really mean it does Y assuming no error
occurs. For example, see the first line of the OPEN statement
description at 09-007[208:9]. Similar for the other I/O statements.
Even the description of simple assignment assumes you don't hit a segfault.
> And we could also say "which errors, if any, are detected is processor
This seems OK. It makes the point that the standard does not have a
list of the errors and error code values somewhere, so the user would
not bother looking.
> --Michael I.
> J3 mailing list
> J3 at j3-fortran.org
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3